Hacker News Reader

Comment by alyandon | Hacker News Reader

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.

View on HN

> 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.

> 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.

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 ; such things lead to a more complicated mental model even if on the surface it looks simpler.

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.

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

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

> "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

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

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.)

Reply on news.ycombinator.com