Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Needs an Official Specification

tweedegolf.nl

Post reply on HN
Print view View original

1–10 of 53 posts

Re: Rust Needs an Official Specification

#5

Post by mr_00ff00 »

I 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 that value really does “destruct” there.

Re: Rust Needs an Official Specification

#7

Post by jmyeet »

So 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 certain point, being able to develop the language without updating a specification is useful. When you reach a certain level of maturity, you need a spec. I think Rust is nearing that inflection point;

2. A spec will make it harder to make breaking changes. That's a good thing. I can't but help think of Python 3. The seal was broken and every point release (it seems) makes breaking changes. That's not a good thing; and

3. A spec doesn't prevent undefined behavior. C/C++ have lots of undefined behavior. Sometimes later spec revisions will address this. Sometimes not.

Re: Rust Needs an Official Specification

#10

Post by etyp »

I 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 there, many times you can read the standard and know what the compiler will do, but many times you can't. Even if the standard is unambiguous.

So with Rust, the implementation is the specification. The author mentioned gccrs - hasn't that already had some positive standardization benefits without a true standard? I'm not super knowledgable about the status there, though.

I feel like more standardization is certainly worthwhile, but writing a specification is an entirely different beast. I see that as years of painstaking work just to keep everything mostly the same and harder to iterate. Seems like a hard sell even if it would be great for systems programmers ;)

> For developing external code analysis tools such as Coverity

You can do that by just using intercepting `rustc` and using the static analysis tool's common IR(s), right? I'm nitpicking here, though.

Post reply on HN