Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust project goals: Immobile types and guaranteed destructors

github.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Rust project goals: Immobile types and guaranteed destructors

#81

Post by spacechild1 »

simonask wrote: post #35
pornel wrote: post #22

Earlier quoted context omitted.

Things you'd expect to work already. It doesn't really add anything new and flashy, but removes some annoying warts. Sync code has scoped threads that enable multi-threaded execution within a function, without having to ensure the data outlives the function call. Async can't do that while guaranteeing safety. This makes tokio::spawn awkward and annoying, and is a major source why people dislike Rust's async. Low-leve…

> and is a major source why people dislike Rust's async It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place. Some languages give the illusion that they support it by boxing the stack frame of async functions and letting a garbage collector deal with the consequences, but that comes with significant drawbacks too (additional GC pressure, heap all…

C++26 adopted senders/receivers (std::execution) as its official concurrency model, with the explicit aim of supporting structured concurrency. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p23...

Re: Rust project goals: Immobile types and guaranteed destructors

#82

Post by afdbcreid »

ameliaquining wrote: post #68
panstromek wrote: post #18

For everybody who doesn't have the context, just note that this is not an accepted langauge change. It's a just project goal, which means it's accepted as something people will work on, but the design might change significantly or it can even be abandoned completely (which is pretty unlikely for this one, to be fair).

I think this one might be at greater risk than usual of being dropped, because it's explicitly mutually exclusive with another accepted project goal (pin ergonomics): https://github.com/rust-lang/rust-project-goals/blob/main/sr...

If anything, pin ergonomics is at greater risk. People still discuss if we need both, but if we don't, then we go for this goal and not pin ergonomics, as it's more general.

It (the immobile types proposal) is at a greater risk because it is a very pervasive and complicated change, and the expected semantics are not fully understood. It might be that there is no way to do this well.

Re: Rust project goals: Immobile types and guaranteed destructors

#83

Post by afdbcreid »

ordu wrote: post #19
q3k wrote: post #16

Earlier quoted context omitted.

> I'm very glad they found a way to add it eventually Will this integrate with existing code that uses Pin ? If not this will split the ecosystem even further...

I don't see why it may fail to integrate. Declare Pin as !Move and... thats all? I mean, there will be issues, edge-cases because it is just how these things happen, but still I don't see any fundamental issues with continuing to use Pin.

Like others said, Pin is incompatible with these semantics. Some people argue, though, that we need both (basically because pinned types can be moved before being pinned).

Re: Rust project goals: Immobile types and guaranteed destructors

#84

Post by afdbcreid »

ameliaquining wrote: post #71
dorjoy wrote: post #63

Does anyone know if there is any plan for no-panic to be a language feature? I think there was some discussion about this regarding Rust in the Linux kernel or embedded Rust but I don't know if there is any consensus or any plan regarding this.

This is not currently a project goal. As with many things in the Rust project, it could be, if someone wanted to step up and dedicate the required engineering resources.

But also come with a plausible implementation strategy, that from what I know is not currently known for no-panic.

Re: Rust project goals: Immobile types and guaranteed destructors

#85

Post by afdbcreid »

klauserc wrote: post #41
stymaar wrote: post #10

Earlier quoted context omitted.

> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that? But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget . It will be like how Arc doesn't implement Send unless .

An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely. Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?

The more accurate definition of `!Forget`, similar to `Pin`, is not "can be leaked" but "if the underlying storage is reused, the destructor is guaranteed to run". This enables all important (decidable - preventing leaking is undecidable, even in GC languages) use-cases, and sending the value to a thread does not break this contract.

Re: Rust project goals: Immobile types and guaranteed destructors

#86

Post by afdbcreid »

safercplusplus wrote: post #33

Ok, I guess somebody has to provide the youngsters/uninitiated with some context. What is going on here can be viewed as part of a process of Rust (potentially) incrementally adopting the C++ model, because the Rust model is limited in important ways. Specifically, Rust's "necessarily-trivial-destructive" moves make it possible for a memory location previously holding a valid object to become invalid without a destru…

One of the main reasons Rust needs this capability is because C++ has it, and Rust wants to interop with it. It's not that better model (enabling it additionally can bring benefits, but also complications; enabling it by default, like C++ does, is a terrible idea).

Re: Rust project goals: Immobile types and guaranteed destructors

#87

Post by MaxBarraclough »

germandiago wrote: post #38

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :) I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...

For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler.

https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...

https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...

https://gcc.gnu.org/gcc-16/changes.html#ada

Re: Rust project goals: Immobile types and guaranteed destructors

#88

Post by panstromek »

kibwen wrote: post #55
germandiago wrote: post #38

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :) I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...

To be clear, this is absolutely not adding any sort of C++-style overrideable implicit move or copy constructor to Rust. There's not really any relationship to C++ in this proposal, it's just a step towards opt-in linear types.

It's relevant for C++ interop at least, but that's about it.

Re: Rust project goals: Immobile types and guaranteed destructors

#89

Post by _alphageek »

Intresting. Immovability becomes a property of the type (!Move) rather than the place (Pin), and the goal is to eventually deprecate Pin outright rather than paper over it with pin ergonomics. !Forge is what finally unblocks safe scoped spawn: handle that can't be mem::forgeten has a destructor that's guaranteed to run.

Re: Rust project goals: Immobile types and guaranteed destructors

#90

Post by yoshuaw »

Dagonfly wrote: post #80
Mond_ wrote: post #76

Earlier quoted context omitted.

Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?

Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture). That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions:

https://blog.yoshuawuyts.com/gen-auto-trait-problem

Post reply on HN