3 ms·

> All the core decisions are the same as in C++ Not at all. In a Rust program, all objects are supposed to be movable via a memcpy (i.e. a bitwise copy) by de

> All the core decisions are the same as in C++ Not at all. In a Rust program, all objects are supposed to be movable via a memcpy (i.e. a bitwise copy) by default. Immovable objects are only supported as an afterthought, via the Pin<> featureset (which is widely regarded as unintuitive, clunky and in need of revision). C++ objects are immovable by default; alternately, they may support custom "move" operators that are closer to the way .take() is used in Rust, i.e. they leave behind the original object in some sort of undetermined state. These are quite significant differences that make it hard to have consistent interop across both languages.

sesm 2y ago
This is interesting. If I want my object to be movable without the need for acquiring the locks for all outbound references, I need my references to be of type 'reference to mutable data'. So that could be one of the reasons why Rust reference types are like this. But what happens to inbound references when I'm moving my object? Who is in charge of updating them?
- steveklabnik 2y ago
  You get a compile time failure. There is no mechanism to automatically update them.
  - sesm 2y ago
    Ok, I see now. This is limited to cases when compiler can prove that the reference is not shared, but still can be useful when adding elements to collections.
    - steveklabnik 2y ago
      Yeah, among other things. It can be used to implement “session types” which basically means encoding a state machine in the type system. So for example, I’m building a web application at work, and users have permissions to access resources. The “please grab a foo from the database” function takes an Authorization as a parameter by move, so in order to call it I have to get one. The only way to get one is to ask the auth subsystem, which checks if a User has the proper permissions. And the only way to get a User is to ask the auth system to authenticate that they have a valid session. So as long as I make my “fetch resources” code require an Authorization as a parameter in the future, I’ll also guarantee that all of the rest of that stuff happens. It’s a little verbose but pretty cool.

sesm 2y ago

This is interesting. If I want my object to be movable without the need for acquiring the locks for all outbound references, I need my references to be of type 'reference to mutable data'. So that could be one of the reasons why Rust reference types are like this. But what happens to inbound references when I'm moving my object? Who is in charge of updating them?

steveklabnik 2y ago
You get a compile time failure. There is no mechanism to automatically update them.
- sesm 2y ago
  Ok, I see now. This is limited to cases when compiler can prove that the reference is not shared, but still can be useful when adding elements to collections.
  - steveklabnik 2y ago
    Yeah, among other things. It can be used to implement “session types” which basically means encoding a state machine in the type system. So for example, I’m building a web application at work, and users have permissions to access resources. The “please grab a foo from the database” function takes an Authorization as a parameter by move, so in order to call it I have to get one. The only way to get one is to ask the auth subsystem, which checks if a User has the proper permissions. And the only way to get a User is to ask the auth system to authenticate that they have a valid session. So as long as I make my “fetch resources” code require an Authorization as a parameter in the future, I’ll also guarantee that all of the rest of that stuff happens. It’s a little verbose but pretty cool.