But then anyone could make a compiler and call it a rust compiler. Can't have that!
There are multiple Rust compilers, for example
Rust Needs an Official Specification
11–20 of 53 posts
Re: Rust Needs an Official Specification
#12One should mention the RustBelt project: https://plv.mpi-sws.org/rustbelt/ here. It was in place to develop a specification for Rust that is accessible for formal verification. I think that is the way to go, rather than semi-formal standadese language. I've some related background and would love to do it (given there was a good postion/pay).
Re: Rust Needs an Official Specification
#13The blog post links to ongoing work on the Rust specification:
> In any case, this ball is rolling! [RFC3355][0] was accepted one year ago, and [a specification team][1] is [at work][2]. We are watching!
[0]: https://rust-lang.github.io/rfcs/3355-rust-spec.html
[1]: https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
[2]: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spe...
Re: Rust Needs an Official Specification
#14I get the author’s point so this may be a useless nitpick but I am not surprised in Rust that drop is called immediately when a value is assigned to _. That’s almost like calling delete in c++ and if you changed the C++ code to a class with a print in the destructor, then called “delete” you would get the same behavior. The “just” underscore in rust I believe is special and basically makes that value inaccessible. So…
It is surprising for a c++ programmer; the equivalent:
auto _ = Foo{};
Re: Rust Needs an Official Specification
#15I feel like the intent of this article is ambiguous. It reads like there is no interest for a descriptive standard and is arguing for one. However, it ends by calling out the standard work in a single sentence. I was expecting to have to call it out as I read the article. I can assume others might not already know about it and miss the last sentence.
As for the motivating example, to me it feels weak from my own experience. In my ~20 years of C++ experience, I've never consulted the standard, in part because of lack of access but also because of the barrier of standardese. I've instead consulted reference documentation geared towards programmers. Even the Ferrocene block they quote, I can see it being hard to connect the dots.
That isn't to say no standard is needed but I doubt most developers will use it.
Re: Rust Needs an Official Specification
#16I have long been pro a specification, but also think that it’s fine so far. I think a lot of people over-weight the need. For example, Rust is being used in safety critical contexts today, a standard is not actually required, only a specification for the specific compiler.
Incidentally, the behavior here is well known, and there’s a subtlety they didn’t quite get to, though they almost did with the quote. Things that impl Drop must be dropped at the end of the lexical scope, but things that don’t can be. So a borrow can end early, but something with custom Drop cannot.
This decision was made because subtly changing when something goes out of scope could make writing unsafe code significantly more difficult and brittle. At the time of the decision, there was already a lot of unsafe code out there, and not breaking it was a priority.
Re: Rust Needs an Official Specification
#17Why is a written specification better than the code that implements it? One might suppose that a written spec is less mutable, but why should that be? The example provided is not particularly good since the semantics are well defined and can be looked up in the code. A better example would be one where what happens is not well defined, but I'm not aware of any of those places in rust.
Essentially, any change to the code that changes the semantics is a breaking change and will be avoided, just as any change to the spec would be a breaking change and would be avoided.
Re: Rust Needs an Official Specification
#18I don't think the C++ standard can be held up like that. Many compilers simply ignore it (or ignored it, they're getting better about these things). It's not because there's an omission, it's because writing a compiler that conforms to a thousand page document of rules is hard. And tedious. Some will fall through, there is no "one true C++" that follows the standard perfectly, most fall short. The ambiguity is still…
[deleted]
Re: Rust Needs an Official Specification
#19I get the author’s point so this may be a useless nitpick but I am not surprised in Rust that drop is called immediately when a value is assigned to _. That’s almost like calling delete in c++ and if you changed the C++ code to a class with a print in the destructor, then called “delete” you would get the same behavior. The “just” underscore in rust I believe is special and basically makes that value inaccessible. So…
For a C++ programmer, the related "suprising" equivalent is to not name the variable. We had a regex linter in our code to ensure locks were named because of bugs from this.
Re: Rust Needs an Official Specification
#20I'm sorry, but even if this exact example does not appear, this case is technically specified by the reference.
The page on identifiers (https://doc.rust-lang.org/reference/identifiers.html) calls out that a "single underscore character is not an identifier". If you then follow the trail (Search for "Underscore"), you will find that it is instead a wildcard pattern (https://doc.rust-lang.org/reference/patterns.html#wildcard-p...). It says that "[u]nlike identifier patterns, it [the wildcard pattern] does not copy, move or borrow the value it matches."
From this, it follows that the right-hand side ("value expression", roughly equal to an rvalue) is not moved into a place called _, but is effectively just a value matched against a wildcard pattern. This does nothing (the value is not moved into any other place), so it gets dropped.