5 ms·

Why can't the rust compiler introduce a hidden temporary variable for the let name = jill.name().first_name() example instead of requiring the developer to expl

Why can't the rust compiler introduce a hidden temporary variable for the let name = jill.name().first_name() example instead of requiring the developer to explicitly declare and use one? Edit: To clarify, I am a Rust neophyte and have only begun to scratch the surface of the language. Edit2: Also, "There is no reason a person should know which class they are in, nor should a class know which people are enrolled in it. " I know what the author is trying to say but when you read that at face value it comes across as a little humorous.

steveklabnik 10y ago
Please see the link to Rust's internals forum I liked below, it goes over this in great detail. (Along with ways we might fix this in the future.)
barrkel 10y ago
Indeed, this is the approach taken in many languages with reference counted types. One problem is that the user would have no way of naming the thing that the lifetime is attached to. Diagnostic messages when trying to hand off 'name' to other code could be perplexing, as the delta between broken code and working code would be larger.
- Groxx 10y ago
  Given their current error messages, that doesn't seem like a problem. If you must name it, call it `name'` or something, but the output could easily be something like 28 | let name = jill.name().first_name(); | ----------- value returned here 28 | let name = jill.name().first_name(); | ^^^^^^^^^^^^^ leaves scope before use, | and is unavailable here
Manishearth 10y ago
> Why can't the rust compiler introduce a hidden temporary variable for the let name = jill.name().first_name() example instead of requiring the developer to explicitly declare and use one? It could, but it doesn't yet. This kind of analysis needs porting borrowck to MIR, which still has to happen. It's too complicated given the current way it works. Though it is a matter of explicit over implicit too. If `name()` had a destructor you may want it to be explicitly tied to a scope by dint of being declared in one instead of floating around in a magical hidden variable that's tied to the scope of a different one. So there are reasons for why it may never be made to work that way.
- feanaro 10y ago
  > Though it is a matter of explicit over implicit too. If `name()` had a destructor you may want it to be explicitly tied to a scope by dint of being declared in one instead of floating around in a magical hidden variable that's tied to the scope of a different one. So there are reasons for why it may never be made to work that way. I'm not sure I see what the problem is with this. It seems like it is very intuitive behaviour in this case and exactly what you would expect.
  - Manishearth 10y ago
    Rust is more explicit about moving and scopes. It's currently very easy to see how long a value will live and where the destructor will run. This somewhat complicates that. This is similar to vvanders' and steve's comments in https://news.ycombinator.com/item?id=13413084 https://news.ycombinator.com/item?id=13413084 ; such things lead to a more complicated mental model even if on the surface it looks simpler.
heeen 10y ago
> "There is no reason a person should know which class they are in, nor should a class know which people are enrolled in it. " Also replacing a O(1) chasing a pointer into a O(n) array search
- db48x 10y ago
  Or with a hash-table lookup, left as an exercise to the reader.
eridius 10y ago
There's an open RFC for this: https://github.com/rust-lang/rfcs/blob/master/text/0066-better-temporary-lifetimes.md https://github.com/rust-lang/rfcs/blob/master/text/0066-bett...

steveklabnik 10y ago

Please see the link to Rust's internals forum I liked below, it goes over this in great detail. (Along with ways we might fix this in the future.)

barrkel 10y ago

Indeed, this is the approach taken in many languages with reference counted types. One problem is that the user would have no way of naming the thing that the lifetime is attached to. Diagnostic messages when trying to hand off 'name' to other code could be perplexing, as the delta between broken code and working code would be larger.

Groxx 10y ago
Given their current error messages, that doesn't seem like a problem. If you must name it, call it `name'` or something, but the output could easily be something like 28 | let name = jill.name().first_name(); | ----------- value returned here 28 | let name = jill.name().first_name(); | ^^^^^^^^^^^^^ leaves scope before use, | and is unavailable here

Manishearth 10y ago

> Why can't the rust compiler introduce a hidden temporary variable for the let name = jill.name().first_name() example instead of requiring the developer to explicitly declare and use one? It could, but it doesn't yet. This kind of analysis needs porting borrowck to MIR, which still has to happen. It's too complicated given the current way it works. Though it is a matter of explicit over implicit too. If `name()` had a destructor you may want it to be explicitly tied to a scope by dint of being declared in one instead of floating around in a magical hidden variable that's tied to the scope of a different one. So there are reasons for why it may never be made to work that way.

feanaro 10y ago
> Though it is a matter of explicit over implicit too. If `name()` had a destructor you may want it to be explicitly tied to a scope by dint of being declared in one instead of floating around in a magical hidden variable that's tied to the scope of a different one. So there are reasons for why it may never be made to work that way. I'm not sure I see what the problem is with this. It seems like it is very intuitive behaviour in this case and exactly what you would expect.
- Manishearth 10y ago
  Rust is more explicit about moving and scopes. It's currently very easy to see how long a value will live and where the destructor will run. This somewhat complicates that. This is similar to vvanders' and steve's comments in https://news.ycombinator.com/item?id=13413084 https://news.ycombinator.com/item?id=13413084 ; such things lead to a more complicated mental model even if on the surface it looks simpler.

heeen 10y ago

> "There is no reason a person should know which class they are in, nor should a class know which people are enrolled in it. " Also replacing a O(1) chasing a pointer into a O(n) array search

db48x 10y ago
Or with a hash-table lookup, left as an exercise to the reader.

eridius 10y ago

There's an open RFC for this: https://github.com/rust-lang/rfcs/blob/master/text/0066-better-temporary-lifetimes.md https://github.com/rust-lang/rfcs/blob/master/text/0066-bett...