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

41–50 of 53 posts

Re: Rust Needs an Official Specification

#41

Post by gpderetta »

epage wrote: post #38
pclmulqdq wrote: post #34

Earlier quoted context omitted.

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.

The gaps are on the standard library side: clang libc++ has fallen behind a bit on conformance, but you can use libstdc++ on clang as well (and it is the default for example on Linux). MSVC lags on C conformance, which is known not to be primary concern for MS (but still miles better than what it used to be).

In any cases these tables only help up to a point, even green cells often hide bugs and conformance divergences.

Still for most straightforward code compliance across compilers is very good and significantly better than the dark ages of two decades ago.

Re: Rust Needs an Official Specification

#42

Post by gpderetta »

hgomersall wrote: post #17

Why 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 c…

The reason is that if the code is the specification is not obvious when a certain behaviour is an intended feature or a bug.

Specifications can have bugs of course, but when the spec and (potentially multiple) implementations agree gives more confidence on expected behaviour.

A conformance suite can be an alternative of course, but it is not necessarily always possible to infer general behaviour from a test case.

Re: Rust Needs an Official Specification

#43

Post by gpderetta »

steveklabnik wrote: post #26
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?)

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.

So the issue really is that the match-and-discard wildcard uses a spelling that would otherwise be a valid identifier name causing an ambiguity to the reader, if not to the compiler.

In retrospect using a different character (say '*') would have been better, clueing the reader that something different was happening; but I guess there is long history of this use of _ in ML languages.

Re: Rust Needs an Official Specification

#44

Post by epage »

gpderetta wrote: post #41
epage wrote: post #38

Earlier quoted context omitted.

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.

The gaps are on the standard library side: clang libc++ has fallen behind a bit on conformance, but you can use libstdc++ on clang as well (and it is the default for example on Linux). MSVC lags on C conformance, which is known not to be primary concern for MS (but still miles better than what it used to be). In any cases these tables only help up to a point, even green cells often hide bugs and conformance divergenc…

Completely agree. I'm only calling it out because of the claim "perfectly conformant with the standard".

Re: Rust Needs an Official Specification

#45

Post by epage »

estebank wrote: post #40
epage wrote: post #19

Earlier quoted context omitted.

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.

For Rust, yes, we do have that and that'd be great to generalize it. That was a C++ code base using custom lock types that I used a regex linter for. Glad to not be touching it anymore for many reasons.

Re: Rust Needs an Official Specification

#46

Post by steveklabnik »

gpderetta wrote: post #43
steveklabnik wrote: post #26

Earlier quoted context omitted.

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.

So the issue really is that the match-and-discard wildcard uses a spelling that would otherwise be a valid identifier name causing an ambiguity to the reader, if not to the compiler. In retrospect using a different character (say '*') would have been better, clueing the reader that something different was happening; but I guess there is long history of this use of _ in ML languages.

I mean, it’s never a valid identifier, and that is spelled out in the reference too.

Re: Rust Needs an Official Specification

#48

Post by gpderetta »

steveklabnik wrote: post #46
gpderetta wrote: post #43

Earlier quoted context omitted.

So the issue really is that the match-and-discard wildcard uses a spelling that would otherwise be a valid identifier name causing an ambiguity to the reader, if not to the compiler. In retrospect using a different character (say '*') would have been better, clueing the reader that something different was happening; but I guess there is long history of this use of _ in ML languages.

I mean, it’s never a valid identifier, and that is spelled out in the reference too.

of course it isn't, it acts as a keyword, but it looks like a valid identifier. As this difference doesn't matter 99% of the time, it can be be easily overlooked, becoming a pitfall the 1% that matters. Of course it too late to change it, but pointing it is a must. I understand rust has a linter pass specifically to catch this sort of issues.

Re: Rust Needs an Official Specification

#49

Post by mcint »

All the nuance is hidden at the end! And not signposted earlier. The example confusion, too thinly justified by common sense and analogy to C++, points to benefit of understanding intermediate compilation stages & how the language understand itself descriptively.

The slippery slope, descriptive, from example confusion to general concerns shows more about the value of learning about design of the language locally relevant to your current problem, than a more indirect solution.

It would serve the case and conversation better, to collect lists of people posting about these issues. Instead of picking a bait title & speaking to it the issue not being relevant.

Despite the title, I agree with the author

> There's no need to change that...[not having a specification] yet. But in ten years, I might feel differently.

I hope he's gotten the engagement & attention he wants.

I'm curious what caused the C++ standard to evolve, what caused there to be so many competing compilers -- their cost, and lack of adequately free, open, and bleeding edge development?

Re: Rust Needs an Official Specification

#50

Post by pclmulqdq »

epage wrote: post #44
gpderetta wrote: post #41

Earlier quoted context omitted.

The gaps are on the standard library side: clang libc++ has fallen behind a bit on conformance, but you can use libstdc++ on clang as well (and it is the default for example on Linux). MSVC lags on C conformance, which is known not to be primary concern for MS (but still miles better than what it used to be). In any cases these tables only help up to a point, even green cells often hide bugs and conformance divergenc…

Completely agree. I'm only calling it out because of the claim "perfectly conformant with the standard".

The compiler is conformant. The STL is not necessarily.
Post reply on HN