4 ms·

> In Rust it's also obvious because every = is a move. False, depending on the presence of an explicit type annotation on the left-hand side, an = triggers eit

> In Rust it's also obvious because every = is a move. False, depending on the presence of an explicit type annotation on the left-hand side, an = triggers either a move or a reborrow.

scotty79 4y ago
How does it look like? Do you mean this? https://haibane-tenshi.github.io/rust-reborrowing/ https://haibane-tenshi.github.io/rust-reborrowing/ If you assume = always moves you can just never use automatic reborrowing (do &mut * instead) and you'll loose nothing. I don't think that's a very common pattern, fully optional and it can be just treated as another exception to the rule, just like Copy types. You don't have to manually write .copy() in some cases, and you don't have to manually write &mut* in some others. But that's what happens. Move is still done. So that's total of two exceptions. Way easier to be tackled individually when the time comes than assuming = means something else, or something complex from the start.
- legerdemain 4y ago
  I've posted similar minimal examples before. The first one triggers a move (and then fails to compile), while the second one triggers a reborrow. Sure, you can explicitly write out every instance of reborrowing with `&mut *`. That would require you to understand every instance that triggers it, and would also be unbelievably noisy, since automatic dereferencing and automatic reborrowing are actually incredibly common. > pub fn main() { > let mut x = String::from("moo"); > let y = &mut x; > let z = y; > println!("{:?}", y) > } > > pub fn main() { > let mut x = String::from("moo"); > let y = &mut x; > let z: &mut _ = y; > println!("{:?}", y) > }
  - scotty79 4y ago
    Ok. So that's just triggering auto-insertion of &mut * It's completely optional fearure. You don't have to rely on it. Like auto-insertion of semicolons in JS maybe it's better if you don't. Although likelihood of this biting you is way lower than in case of relying on semicolons autoinsertion.
    - legerdemain 4y ago
      It's "completely optional" in the sense that in several years of reading other people's Rust code, I have never seen anyone explicitly use it throughout a code base. It is utterly ubiquitous, rarely explained, and poorly (if at all) understood by a large majority of Rust users I've mentioned it to. My claim is that for most Rust users, understanding the borrow checker is limited to a few heuristics that seem to work for them 80% of the time, and throwing up their hands and declaring an approach unworkable the remaining 20% of the time. To a first approximation, no one can mentally model the borrow checker beyond extremely simple examples of 4-5 lines of code.
- puffoflogic 4y ago
  There's a way of thinking of `Copy` which makes it not an exception: `Copy` variables/places are simply not rendered invalid/uninitialized when they are the source of a move operation, unlike non-`Copy` sources. They're still moved from bitwise like all other rust values!
  - scotty79 4y ago
    I like it!
deleted 4y ago
[deleted]

> In Rust it's also obvious because every = is a move. False, depending on the presence of an explicit type annotation on the left-hand side, an = triggers either a move or a reborrow.

scotty79 4y ago

How does it look like? Do you mean this? https://haibane-tenshi.github.io/rust-reborrowing/ https://haibane-tenshi.github.io/rust-reborrowing/ If you assume = always moves you can just never use automatic reborrowing (do &mut * instead) and you'll loose nothing. I don't think that's a very common pattern, fully optional and it can be just treated as another exception to the rule, just like Copy types. You don't have to manually write .copy() in some cases, and you don't have to manually write &mut* in some others. But that's what happens. Move is still done. So that's total of two exceptions. Way easier to be tackled individually when the time comes than assuming = means something else, or something complex from the start.

legerdemain 4y ago
I've posted similar minimal examples before. The first one triggers a move (and then fails to compile), while the second one triggers a reborrow. Sure, you can explicitly write out every instance of reborrowing with `&mut *`. That would require you to understand every instance that triggers it, and would also be unbelievably noisy, since automatic dereferencing and automatic reborrowing are actually incredibly common. > pub fn main() { > let mut x = String::from("moo"); > let y = &mut x; > let z = y; > println!("{:?}", y) > } > > pub fn main() { > let mut x = String::from("moo"); > let y = &mut x; > let z: &mut _ = y; > println!("{:?}", y) > }
- scotty79 4y ago
  Ok. So that's just triggering auto-insertion of &mut * It's completely optional fearure. You don't have to rely on it. Like auto-insertion of semicolons in JS maybe it's better if you don't. Although likelihood of this biting you is way lower than in case of relying on semicolons autoinsertion.
  - legerdemain 4y ago
    It's "completely optional" in the sense that in several years of reading other people's Rust code, I have never seen anyone explicitly use it throughout a code base. It is utterly ubiquitous, rarely explained, and poorly (if at all) understood by a large majority of Rust users I've mentioned it to. My claim is that for most Rust users, understanding the borrow checker is limited to a few heuristics that seem to work for them 80% of the time, and throwing up their hands and declaring an approach unworkable the remaining 20% of the time. To a first approximation, no one can mentally model the borrow checker beyond extremely simple examples of 4-5 lines of code.
puffoflogic 4y ago
There's a way of thinking of `Copy` which makes it not an exception: `Copy` variables/places are simply not rendered invalid/uninitialized when they are the source of a move operation, unlike non-`Copy` sources. They're still moved from bitwise like all other rust values!
- scotty79 4y ago
  I like it!

deleted 4y ago

[deleted]