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

61–70 of 112 posts

Re: Rust project goals: Immobile types and guaranteed destructors

#61

Post by Dagonfly »

simonask wrote: post #59
Dagonfly wrote: post #57

Earlier quoted context omitted.

The compat issue has always been associated types on std traits. For example, should Iterator::Item be Move or ?Move If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now. The most critical trait is probably Deref. Using !Mo…

I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`. But yeah I can see how these bounds are somewhat viral. Thanks!

Here is an example of the problem: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.

Re: Rust project goals: Immobile types and guaranteed destructors

#64

Post by safercplusplus »

simonask wrote: post #39
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…

I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standard support for expressing immobility) doesn't just cover the object's own location, but also any references derived from the object, commonly called "pin projection". For example, if you have a `Pin >>`, it's safe to turn that into a `Pin `.…

Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin`) are concerned about is whether an object can be (destructively) moved. You're pointing out a reference derived from a pinning reference essentially inheriting the pinning property. (I.e. the property that the target won't be inappropriately (destructively) moved.)

But with this proposal, the property that the object won't be (destructively) moved is (solely) a property of the object's type. Specifically, it doesn't depend on any property of any reference to the object, and certainly not on any other reference that that reference was derived from, right?

> Any system that replaces `Pin` will probably have to maintain that same property

Maybe any system that compatibly replaces `Pin`. Maybe. But I'm not sure that this proposal is overly concerned with compatibility with `Pin`. That github page explicitly mentions the desire to deprecate `Pin`, right? And like I suggested, if successful enough, it's conceivable that it could end up de facto deprecating Rust's necessarily-trivial-destructive moves in general. Conceivably.

Re: Rust project goals: Immobile types and guaranteed destructors

#65

Post by barrkel »

groundzeros2015 wrote: post #62

Guaranteed destructors is probably the most complex features ever added to C++, more than templates or move semantics.

The combination of exceptions and non-trivial {copy constructor, assignment operator, destructor} are what combine to make C++ a somewhat broken language when you try to use all the features. And also responsible for poisoning the well for exceptions as an error handling mechanism for native code.

Delphi did native exceptions much better IMO.

Re: Rust project goals: Immobile types and guaranteed destructors

#66

Post by Falell »

OskarS wrote: post #6

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? Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around that?

This was my first question too, I don't see anything addressing e.g. the cyclical arc example from the original 'spawn' conversation.

It seems like you have to auto-propagate !Forget, and then make 'anything that be used to logically implement forget', probably most importantly things like Rc take a Forget bound and do it at an edition boundary? But the link mentions none of that...

Re: Rust project goals: Immobile types and guaranteed destructors

#68

Post by ameliaquining »

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...

Re: Rust project goals: Immobile types and guaranteed destructors

#69

Post by ameliaquining »

q3k wrote: post #16
stymaar wrote: post #8

Great new! Since 2016 or so it became apparent that immovable types were a crucial missing part of Rust, but for a long time it was believed it wouldn't be possible to add them without breaking everything, which is why we ended up with the Pin hack. I'm very glad they found a way to add it eventually, as it's really filling a glaring hole in the language.

> 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...

They recognize that there's going to have to be some kind of compatibility or migration story for existing APIs based on Pin, but have decided to punt that question to next year. For now, the focus is on the non-async-related use cases for these new language features (for which Pin is already insufficient); once those are known to work, then they'll shift focus to letting the async ecosystem benefit too.

Re: Rust project goals: Immobile types and guaranteed destructors

#70

Post by ameliaquining »

barrkel wrote: post #65
groundzeros2015 wrote: post #62

Guaranteed destructors is probably the most complex features ever added to C++, more than templates or move semantics.

The combination of exceptions and non-trivial {copy constructor, assignment operator, destructor} are what combine to make C++ a somewhat broken language when you try to use all the features. And also responsible for poisoning the well for exceptions as an error handling mechanism for native code. Delphi did native exceptions much better IMO.

How do native exceptions work in Delphi?
Post reply on HN