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

31–40 of 53 posts

Re: Rust Needs an Official Specification

#31

Post by delta_p_delta_x »

jmyeet wrote: post #7

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 cert…

`_` in a lot of languages is called a discard or wildcard. It comes from Rust's ML heritage, and that's essentially what it does in ML too. C# has something similar. It's not unexpected at all, especially given how the syntactic feature is described.

Re: Rust Needs an Official Specification

#33

Post by oguz-ismail »

sealeck wrote: post #11
Brian_K_White wrote: post #2

But then anyone could make a compiler and call it a rust compiler. Can't have that!

There are multiple Rust compilers, for example - https://github.com/Rust-GCC/gccrs - https://github.com/thepowersgang/mrustc

they are both incomplete

Re: Rust Needs an Official Specification

#34

Post by pclmulqdq »

etyp wrote: post #10

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…

The major C++ compilers are perfectly conformant with the standard. Where they can lag is after standards come out. Modules have been a challenge, but other language features get implemented within a few years. At the time of writing, all the major compilers conform with C++ 17 and aside from modules, conform with C++ 20. There absolutely is "one true C++" as set by the standard, and compiler writers have a roadmap for how to conform to it.

"The implementation is the specification" is frankly a sophomoric position. It works fine for small projects and projects of limited complexity, but Rust is neither of these.

Re: Rust Needs an Official Specification

#35

Post by jmyeet »

gpderetta wrote: post #23
jmyeet wrote: post #7

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

Those are two different things.

- A _ prefix tells the compiler not to warn you a variable isn't used.

- A _ variable name is a reserved symbol to say something cannot be used. Trying to do so will cause a compiler error.

So they're scoped differently.

Consider this Go snippet:

    func A() { fmt.Println("A") }
    func B() { fmt.Println("B") }
    func main() {
      var B = A;
      B()
    }
What function gets called? It's A but you can reasonably make a case for B given the capitalization of Go function names and variables. My point is that scoping and resolution rules and many other aspects of a language can be viewed as intuitive (or not) based simply on what you're used to. Even then they can be arbitrary.

Re: Rust Needs an Official Specification

#36

Post by Brian_K_White »

oguz-ismail wrote: post #33
sealeck wrote: post #11

Earlier quoted context omitted.

There are multiple Rust compilers, for example - https://github.com/Rust-GCC/gccrs - https://github.com/thepowersgang/mrustc

they are both incomplete

Does that matter? I was saying that rust doesn't want anyone else to use the word rust, even beyond what I would consider their right to.

This comment was showing that there are other projects using the word rust in their name & description.

The progress of those projects doesn't change the fact that they exist and call themselves rust compilers.

Re: Rust Needs an Official Specification

#37

Post by gpderetta »

jmyeet wrote: post #35
gpderetta wrote: post #23

Earlier quoted context omitted.

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

Those are two different things. - A _ prefix tells the compiler not to warn you a variable isn't used. - A _ variable name is a reserved symbol to say something cannot be used. Trying to do so will cause a compiler error. So they're scoped differently. Consider this Go snippet: func A() { fmt.Println("A") } func B() { fmt.Println("B") } func main() { var B = A; B() } What function gets called? It's A but you can reas…

In a language where functions are in the same namespace as variables (like the majority of languages), I would expect A, in a lisp-2 I would expect B.

But I don't see how's that relevant, this is not about the scope of bindings, but about the lifetime of objects.

As Steve explained in a sibling comment, _ is in fact not a variable name, and doesn't extend the lifetime of the object. The semantic is perfectly reasonable and I'm sure it has a good reason to be that way, but the difference between two similarly looking syntaxes is surprising and violates the principle of least astonishment.

FWIW, C++ temporary lifetime extensions are also surprising in many cases.

[Note: I don't know if rust is defined in term of temporary lifetime extensions, it is just a way to understand it for a c++ programmer like me]

Re: Rust Needs an Official Specification

#38

Post by epage »

pclmulqdq wrote: post #34
etyp wrote: post #10

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…

The major C++ compilers are perfectly conformant with the standard. Where they can lag is after standards come out. Modules have been a challenge, but other language features get implemented within a few years. At the time of writing, all the major compilers conform with C++ 17 and aside from modules, conform with C++ 20. There absolutely is "one true C++" as set by the standard, and compiler writers have a roadmap f…

Looking over https://en.cppreference.com/w/cpp/compiler_support, it seems there is good conformance on C++11 and C++14 but there are gaps on C++17+ among gcc, msvc, and clang.

Re: Rust Needs an Official Specification

#39

Post by steveklabnik »

gpderetta wrote: post #37
jmyeet wrote: post #35

Earlier quoted context omitted.

Those are two different things. - A _ prefix tells the compiler not to warn you a variable isn't used. - A _ variable name is a reserved symbol to say something cannot be used. Trying to do so will cause a compiler error. So they're scoped differently. Consider this Go snippet: func A() { fmt.Println("A") } func B() { fmt.Println("B") } func main() { var B = A; B() } What function gets called? It's A but you can reas…

In a language where functions are in the same namespace as variables (like the majority of languages), I would expect A, in a lisp-2 I would expect B. But I don't see how's that relevant, this is not about the scope of bindings, but about the lifetime of objects. As Steve explained in a sibling comment, _ is in fact not a variable name, and doesn't extend the lifetime of the object. The semantic is perfectly reasonab…

The definitions are a bit different than in C++ but the overall effect is the same: https://doc.rust-lang.org/stable/reference/expressions.html#...

Re: Rust Needs an Official Specification

#40

Post by estebank »

epage wrote: post #19
mr_00ff00 wrote: post #5

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…

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.

You mean like `clippy::let_underscore_lock`? I'd like it if there was an annotation for arbitrary types to declare that they behave like a lock so that the lint would pick them up too.
Post reply on HN