4 ms·

I believe rust is sort of similar in that apart from the references, it's very heavy on the move semantics. And IIRC, sometimes it's doing extra memcpys. But I

I believe rust is sort of similar in that apart from the references, it's very heavy on the move semantics. And IIRC, sometimes it's doing extra memcpys. But I don't know if Rust is explicitly targeting const reference passing. That said, if you're all in on it I imagine that the front-end could pretty aggressively target that, much like how rust uses no alias.

saghm 3y ago
By default, non-references in Rust are passed by move, although you can derive `Clone` on types composed of all `Clone` types and then explicitly call the `.clone()` method to copy things. The only types that will be copied by default are the ones that implement `Copy` in addition to `Clone`, which in the standard library is on primitives like integers and characters but overall is used fairly sparingly. References need to be specified as mutable if mutation is needed (i.e. `&mut T` instead of just `&T`). Using immutable references is also encouraged from the borrow checking rules; having a second reference (either mutable or immutable) alive at the same time as a mutable one is a compiler error, but using multiple immutable references at the same time is fine. (Pointers are the same way, but not really used much outside of bridging with unsafe Rust, since they can be null and therefore can't be dereferenced outside of `unsafe` blocks).
- SkiFire13 3y ago
  I think OP was referring to the fact that implementation of moves can sometime (more often than desired I would add) do memcpys. e.g. if you have a struct of ~100 bytes and you move it, it will probably emit a memcpy to write it in the receiving function's stack. AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers.
  - gpderetta 3y ago
    > addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code This is certainly the case in c++: distinct objects have distinct addresses, so to remove a copy the compiler has to prove that the aliasing is not observable which is hard. But does rust have the same guarantee?
  - saghm 3y ago
    > AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers. I honestly don't understand what you've said here at all. I'm not familiar with what "observable" means in this context, and googling "observable aliases programming languages" didn't help clarify it (two results were articles about C/C++ aliasing, one of which used the term "observable" once but didn't seem to define it at all, and the other which was the Wikipedia article on "Aliasing (computing)" that didn't contain the term at all). Even if I knew what "observable" meant, I think you might be missing a negation (or maybe including one you didn't mean to) somewhere; if addresses are "kinda considered observable", it's not obvious why it would be an issue to omit copies and "be observable". Maybe understanding what's meant by "observable" would shed some light on what you mean here, but naively, I don't understand how code that expects things to "kind of" hold a property would break if that property were somehow more strongly held.

saghm 3y ago

By default, non-references in Rust are passed by move, although you can derive `Clone` on types composed of all `Clone` types and then explicitly call the `.clone()` method to copy things. The only types that will be copied by default are the ones that implement `Copy` in addition to `Clone`, which in the standard library is on primitives like integers and characters but overall is used fairly sparingly. References need to be specified as mutable if mutation is needed (i.e. `&mut T` instead of just `&T`). Using immutable references is also encouraged from the borrow checking rules; having a second reference (either mutable or immutable) alive at the same time as a mutable one is a compiler error, but using multiple immutable references at the same time is fine. (Pointers are the same way, but not really used much outside of bridging with unsafe Rust, since they can be null and therefore can't be dereferenced outside of `unsafe` blocks).

SkiFire13 3y ago
I think OP was referring to the fact that implementation of moves can sometime (more often than desired I would add) do memcpys. e.g. if you have a struct of ~100 bytes and you move it, it will probably emit a memcpy to write it in the receiving function's stack. AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers.
- gpderetta 3y ago
  > addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code This is certainly the case in c++: distinct objects have distinct addresses, so to remove a copy the compiler has to prove that the aliasing is not observable which is hard. But does rust have the same guarantee?
- saghm 3y ago
  > AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers. I honestly don't understand what you've said here at all. I'm not familiar with what "observable" means in this context, and googling "observable aliases programming languages" didn't help clarify it (two results were articles about C/C++ aliasing, one of which used the term "observable" once but didn't seem to define it at all, and the other which was the Wikipedia article on "Aliasing (computing)" that didn't contain the term at all). Even if I knew what "observable" meant, I think you might be missing a negation (or maybe including one you didn't mean to) somewhere; if addresses are "kinda considered observable", it's not obvious why it would be an issue to omit copies and "be observable". Maybe understanding what's meant by "observable" would shed some light on what you mean here, but naively, I don't understand how code that expects things to "kind of" hold a property would break if that property were somehow more strongly held.