An Informal Introduction to Move-Only Types

Uhm sorry, but… Rust has “nil”, it is the “none case of an optional”, so exactly the same: std::option - Rust

3 Likes

In Rust you have no possibility to set references to nil because they are not of any option type or any functionality of an option type.

In Rust when when you move, the variable that you move from is invalidated at compile time. Swift has an option to invalidate references at runtime by just setting them to nil.

Rust and Swift make the same optimization that an option(al) of a reference type is the same size as the normal one, and that the “none” case is represented as 0.

Can you give a demonstration in code that explains your concern?

And specifically, your concern about move-only types being set to nil and why you feel that is especially problematic/unclear?

It was refection when it comes to the "partial move" discussion. When you move member references out of a struct for example. In Rust you cannot pass on such struct as all references must have a value (often remedied by making it an optional). If Swift allow move types to be nil, Swift doesn't need such check.

I don’t think there’s any world in which Swift would introduce implicit nil references.

3 Likes

Forget it, I was just thinking about making the move type act like an optional in order to avoid compile time checks and new corner cases. This is obviously not what you want anyway.

Yes, the basic idea for move-only types is to eliminate rum time checks (thus supporting very fast code) by doing additional safety checks at compile time.

1 Like