71–80 of 112 posts
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.
Earlier quoted context omitted.
Which stdlib collections and types should become `!Move`?
None. The question is more what happens when you put a `!Move` type into, say, `Vec `, because that's a collection type that regularly moves its elements to a new allocation when it grows or shrinks. Should it be possible to construct a `Vec ` whose size can never change? Is there a subset of Vec's API that can be annotated with `where T: ?Move`? These are all important design questions, with the potential to break 9…
Earlier quoted context omitted.
The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like with `?Sized`. In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.
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…
Earlier quoted context omitted.
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 (destructiv…
So if Rust ever gains move constructors, you'll probably have to call them explicitly, the way you have to explicitly call .clone(). (There's actually already a third-party library that does something like this (https://docs.rs/moveit), and I think Crubit is using a similar API to let Rust code call C++ move constructors.)
Earlier quoted context omitted.
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?
The major differences with C++:
* objects are references not values, cutting out all the copy constructor,
assignment operator, destruction on out of scope etc.
* objects are zero-initialized after allocation and before constructors run
* constructors are run from most derived to least derived
* calling Free method checks if Self is nil
* this + zero init means that you can call '.Free' on all the objects you
reference in the destructor without checking if they're nil first,
handling partial construction
Earlier quoted context omitted.
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
> the point of Pin is to wrap types that CAN move. I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place. Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place. Meanwhile, !Move types can't ever move. The object has to remain in the inital place it w…
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.
Earlier quoted context omitted.
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type. But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
Earlier quoted context omitted.
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
> the point of Pin is to wrap types that CAN move. I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place. Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place. Meanwhile, !Move types can't ever move. The object has to remain in the inital place it w…
You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:
enum StateMachine {
InitialState,
State1(String),
State2(Box),
TerminalState,
}Earlier quoted context omitted.
> the point of Pin is to wrap types that CAN move. I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place. Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place. Meanwhile, !Move types can't ever move. The object has to remain in the inital place it w…
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?
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.