[deleted]
Rust Needs an Official Specification
21–30 of 53 posts
Re: Rust Needs an Official Specification
#22A spec would only help with this if you read the spec.
Re: Rust Needs an Official Specification
#23So I'm no Rust expert but when I saw: let _ = Foo; my immeidate thought was "this is going to get cleaned up immediately", which turns out to be the case. If you come from a language where braces define scopes and variables only get cleaned up when a variable goes out of scope, Rust's behavior may be surprising but it's consistent and correct. The object is immediately out of scope. Three thoughts: 1. Up until a cert…
But in this it is not.
let _tmp = Foo;
Re: Rust Needs an Official Specification
#24Re: Rust Needs an Official Specification
#25[flagged]
[deleted]
Re: Rust Needs an Official Specification
#26So I'm no Rust expert but when I saw: let _ = Foo; my immeidate thought was "this is going to get cleaned up immediately", which turns out to be the case. If you come from a language where braces define scopes and variables only get cleaned up when a variable goes out of scope, Rust's behavior may be surprising but it's consistent and correct. The object is immediately out of scope. Three thoughts: 1. Up until a cert…
But in this it is not. let _tmp = Foo; The confusing bit is renaming the object from _tmp to _ changes the rules. I assume that in rust '_' is not an actual name, but a pattern to be matched, but even that the actual rule applied is not obvious (does it match everything? Only the lifetime of objects matched with a name is extended?)
Correct, _ is a pattern that does not bind to any name. While the implications of that may not be simple, the description certainly is.
Names that start with underscores are still names, and work like any other name. The “unused variable” into can be suppressed with a leading underscore like any other name, but that’s purely about the lint and not semantics.
Re: Rust Needs an Official Specification
#27This quirk needs to be in a tutorial or a developer-oriented reference. Involving an ISO committee in this wouldn't produce a document that makes it any easier to understand it.
This is because from the language perspective, there's no such feature. It's just a surprising combination a wildcard pattern that doesn't bind, and a drop scope of temporaries created in expressions. Each of these features is independent of the other, and are documented separately.
The Ferrocene specification and the Rust reference are almost identical in this regard:
https://doc.rust-lang.org/reference/destructors.html#drop-sc... https://doc.rust-lang.org/reference/patterns.html#widcard-pa...
These features should be described more precisely, but because `let _ = temp` is not a special case, but a regular case of `let PATTERN = EXPR`, a formal spec wouldn't redundantly document that combination.
Understanding Drop order doesn't need a spec, but needs all of the relevant bits of the specification extracted and described in one place. For example, the spec is pretty clear that `if let` is translated to an equivalent `match` statement, which is sufficient to implement it. What it doesn't spell out for the readers, is that scope of temporaries in `match` covers the entire match statement, and this happens to include `_ => {}` fallback pattern for the `else` in `if let`, so temporaries from the condition are still alive in the else block. This is a surprising quirk, but the surprise doesn't come from lack of specification, just lack of end-user-friendliness of the spec format, and you shouldn't expect a formal spec to be a tutorial.
Re: Rust Needs an Official Specification
#28So I'm no Rust expert but when I saw: let _ = Foo; my immeidate thought was "this is going to get cleaned up immediately", which turns out to be the case. If you come from a language where braces define scopes and variables only get cleaned up when a variable goes out of scope, Rust's behavior may be surprising but it's consistent and correct. The object is immediately out of scope. Three thoughts: 1. Up until a cert…
> If you come from a language where braces define scopes [...] Rust's behavior may be surprising but it's consistent and correct. The object is immediately out of scope.
As someone from a language background where braces define scopes the behavior currently demonstrated is actually perfectly in alignment with my expectation. The variable is never even entering the block scope defined by the function boundary. The variable was created within the temporary scope of the line and then is destroyed because no symbols exiting that line were binding it to a value. Aka - the variable never formally entered the symbol table for that block.
Maybe a standard of some kind encoding these changes would be helpful but I did live through the 20 billion different C compiler era and, tbh, if you weren't trying to be fancy you could usually get shit done - standards require a large upfront and continual maintenance cost and I'd prefer to see some actually dangerous ambiguous operations before the community invested in one.
Re: Rust Needs an Official Specification
#29So I'm no Rust expert but when I saw: let _ = Foo; my immeidate thought was "this is going to get cleaned up immediately", which turns out to be the case. If you come from a language where braces define scopes and variables only get cleaned up when a variable goes out of scope, Rust's behavior may be surprising but it's consistent and correct. The object is immediately out of scope. Three thoughts: 1. Up until a cert…
Mostly, the ANSI 89 C standard ensured portability, and long-term core functionality of ecosystems through bootstrap compilers etc. Arguably, the standards compliance was indirectly responsible for the gcc becoming popular.
The issue with modern C++, was users that began to mix core features with externally defined popular abstract Standard Template Library feature implementations. i.e. while an attempt was made to bring the compiler features into global harmony. The outcome was an ever spiraling complexity with conflicting use-cases, and multiple valid justifications in every case.
Rust will likely end up like NodeJS/PHP/C++ ecosystems... not simply because of llvm quality issues, but rather it is human nature to check-off all prerequisites for a "Second-system effect".
YC has shown some of the proponents are irrationally fanatical, and unfortunately all too predictable... one may append the standard AstroTurf opinions that deny reality below... =3
Re: Rust Needs an Official Specification
#30The documentation for destructors actually does contain the answer to their motivating example [0]. It's difficult to read, but it's there, and it thoroughly explains what's happening here. Local variable bindings have the scope of the block they're in. Other expressions have a temporary scope. The _ wildcard pattern is documented [1], and is explicitly not an identifier pattern. The documentation specifically says that it does not copy, move, or borrow values. Therefore, expressions on the right hand side of a let that uses _ as the pattern do not bind to a value and therefore use a temporary scope.
Yes, the language here is difficult to understand, but that's true of specifications as well. Just like with these docs, you'll have to refer to multiple sections of the spec in order to piece together the expected behavior.
There may be other reasons for a spec (it puts different implementations on equal footing instead of having one official reference implementation), but in this case if the reference is hard to follow I don't see any reason to believe a spec would be better.
[0] https://doc.rust-lang.org/reference/destructors.html#tempora...
[1] https://doc.rust-lang.org/reference/patterns.html#wildcard-p...