4 ms·

As the person who originally pushed extremely hard for all of the lifetime elision that we have today, I agree with you that this case is still too verbose. Th

by wycats 11y ago

As the person who originally pushed extremely hard for all of the lifetime elision that we have today, I agree with you that this case is still too verbose. That said, the reason it wasn't included in the original elision RFC (https://github.com/rust-lang/rfcs/pull/141 https://github.com/rust-lang/rfcs/pull/141) is that the design space here is a little bit more subtle than some of the cases that did make it. In particular, I believe that it's important to know that a particular struct contains a borrowed value somewhere. So let's say you could leave off the `'c` on the Sheep struct, and I wrote a struct containing `Sheep`: struct Flock { sheep: Vec<Sheep> } Now, we have visually lost the fact that a borrowed value is stored inside the flock. Since data structures can get very recursive, this rapidly causes useful information about ownership to get lost. What I'd like to see personally is: struct Sheep<&> { age: &i32 } struct Flock<&> { sheep: Vec<Sheep> } What this would mean is that you can always see, by looking at a struct definition, whether it contains borrowed values (anywhere recursively), but without the grotty need to define and wire up lifetime names. I like the fact that this maintains the strong mental notion of ownership (the meaning of the & "operator" in Rust), but, as with normal elision, it eliminates the wiring that a good compiler should be able to do for you.

dan00 11y ago
There're even people that don't like the automatic moving in Rust, because they can't see where something is moved. I can understand why people feel that way, but it's a bit irrational, because if automatic behaviour can't result into incorrect code, more ressource usage or higher work load, why should I care about? I have pretty much the same feeling about explicit lifetimes in this example. Again, I understand that people want the whole control, want to see every relevant information, but everything has its costs, and the relevant information in each use case isn't always the same.
- steveklabnik 11y ago
  We did try making moves and copies into distinct syntaxes. let x = foo; // <- copies let x = move foo; // <- moves It was worse, or at least, was by the majority of people at the time. See http://smallcultfollowing.com/babysteps/blog/2012/10/01/moves-based-on-type/ http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... for more of this ancient history.
- kzrdude 11y ago
  Thankfully there are no move constructors in Rust, so moving something is entirely bug- and side effect free.

by wycats 11y ago

dan00 11y ago

There're even people that don't like the automatic moving in Rust, because they can't see where something is moved. I can understand why people feel that way, but it's a bit irrational, because if automatic behaviour can't result into incorrect code, more ressource usage or higher work load, why should I care about? I have pretty much the same feeling about explicit lifetimes in this example. Again, I understand that people want the whole control, want to see every relevant information, but everything has its costs, and the relevant information in each use case isn't always the same.

steveklabnik 11y ago
We did try making moves and copies into distinct syntaxes. let x = foo; // <- copies let x = move foo; // <- moves It was worse, or at least, was by the majority of people at the time. See http://smallcultfollowing.com/babysteps/blog/2012/10/01/moves-based-on-type/ http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... for more of this ancient history.
kzrdude 11y ago
Thankfully there are no move constructors in Rust, so moving something is entirely bug- and side effect free.