
Rust turns three - steveklabnik
https://blog.rust-lang.org/2018/05/15/Rust-turns-three.html
======
kibwen
The 1.0 release still feels like it was just yesterday. :)

As with any mention of Rust 2018 and the rustfix tool, I want to emphasize how
seriously compatibility is being taken:

 _> You can use old editions indefinitely on new compilers; editions are opt-
in.

> Editions are set on a per-crate basis and can be mixed and matched; you can
> be on a different edition from your dependencies.

> Warning-free code in one edition must compile, and have the same behavior,
> on the next.

> Edition-related warnings, e.g. that an identifier will become a keyword in
> the next edition, must be easily fixable via an automated migration tool
> (rustfix). Only a small minority of crates should require any manual work to
> opt in to a new edition, and that manual work must be minimal.

> Most new features are edition-independent, and will be usable on new
> compilers even when an older edition is selected._

[https://blog.rust-lang.org/2018/03/12/roadmap.html](https://blog.rust-
lang.org/2018/03/12/roadmap.html)

~~~
rascul
> Most new features are edition-independent, and will be usable on new
> compilers even when an older edition is selected.

What happens when you have specified an older edition, but use a feature from
a newer edition (possibly without realizing it's from a newer edition), it
works fine on your newer edition compiler, then try and build it on a compiler
supporting only the older edition? Is that a potential issue or am I
interpreting it incorrectly? It kinda seems like maybe features should be
edition dependent.

~~~
steveklabnik
It's not 100% clear to me what you're seeing as the issue here.

> but use a feature from a newer edition (possibly without realizing it's from
> a newer edition)

You'd have to specify the newer edition for it to work.

> try and build it on a compiler supporting only the older edition?

This is kind of a moot point given that there's only one real compiler right
now, but it would fail to compile.

~~~
rascul
> You'd have to specify the newer edition for it to work.

That seems to contradict this:

> Most new features are edition-independent, and will be usable on new
> compilers even when an older edition is selected.

I understand it's currently a moot point, I'm just trying to understand if I'm
interpreting it correctly.

~~~
steveklabnik
If it's an edition-independent feature, then it doesn't require the newer
edition, so a compiler that doesn't support the new edition wouldn't have any
problems.

Maybe it would help to step through a strawman?

Let's say that "impl Trait" didn't land last week, but lands six months from
now, after the 2018 edition ships. Alice is working on a library project using
the 2015 edition. She uses "impl Trait". Since it doesn't require the 2018
edition, it just works. Bob uses Alice's library, and uses a compiler that
doesn't support Rust 2018. That's fine, as Alice hasn't used any 2018 specific
things.

That's my understanding of the scenario you're talking about. Did I get it
right?

The other scenario would be this:

It's 2019. Alice is working on a library project using the 2015 edition. She
tries to use the "catch" keyword, which requires edition 2018. When she tries
to use it, her code will fail to compile. She has two choices: 1. not use the
feature 2. update to edition 2018. If she chooses the latter, when Bob tries
to use her library later, but his compiler doesn't support the 2018 edition,
it will fail to compile.

This is basically all of the usual backwards and forwards compatibility stuff,
even without editions. If you try to use ? on a 1.0 version of rustc, your
code won't compile, as that was added much later.

~~~
rascul
Thank you for the explanation, I believe I understand it now. I had originally
interpreted that in a manner to assume that all new features would be tagged
with an edition but would be usable on older editions if the compiler
supported the feature, but with your explanation I realized that my
interpretation of "edition-independent" was off the mark.

~~~
steveklabnik
Great! Glad to get it sorted. That's a totally reasonable interpretation; we
had to debate if that's the way we wanted to do it, or not. In the end, it
seemed to mostly add complexity to remove features from people, and that seems
like a bad tradeoff.

------
webkike
For me, Rust has made programming fun again. And I find that a langauge has
done that maybe twice in my programming career.

I love Rust. It's fun and fast.

------
mjw1007
I have one gripe about Rust:

The Rust people appear to be actively proud of their documentation, and they
appear to be proud of their memory model.

But the documentation of the memory model in the reference manual is seven
short paragraphs of waffle, mostly defining various words in terms of other
undefined words.

I was mildly surprised at the state of the reference manual when they declared
1.0, and I'm distinctly disappointed that it's still so bad.

~~~
kibwen
The Rust memory model is basically "the C11 memory model, except static checks
prevent the unsound parts". We don't have much of a choice, given that we
basically pretend to be C at the LLVM IR level and that we want to heavily
leverage LLVM's existing optimization passes, which were designed with C in
mind.

The "reference" isn't normative, it's just an unprincipled dumping ground for
random bits of syntax and semantics and probably should have been deleted
years ago, or at least renamed to something with less authoritative weight
than "reference" to avoid misleading people as it often does. The Rust devs
absolutely do want to thoroughly specify the language someday, though the
immediate priority is making sure that Rust survives its first ten years.

~~~
steveklabnik
> it's just an unprincipled dumping ground

This is not the case, and I don't appreciate you disparaging others' hard work
like this.

The reference is _accurate_ , but not _complete_. Anything inaccurate is a
bug, and if they're found, we fix them like any other.

~~~
kibwen
_> > it's just an unprincipled dumping ground

> This is not the case, and I don't appreciate you disparaging others' hard
> work like this._

It is the minimally-charitable interpretation of my statement to assume that
I'm trying to disparage the people behind the reference. The document itself
is lacking, which is a statement we can make about many nightly/unstable
things without disparaging the people working on them; exacerbated in this
case because the reference ships as part of the stable documentation, which
implies a degree of quality that it does not yet live up to, especially given
the high expectations that people have when they of a language reference
document such as ECMAScript's or ISO C++.

Starting from the first page of the reference, Notation: [https://doc.rust-
lang.org/stable/reference/notation.html](https://doc.rust-
lang.org/stable/reference/notation.html)

The first paragraph links to a section on special Unicode productions. This
section defines identifiers in terms of Unicode's XID_start and XID_continue,
but this is referring to the unstable non_ascii_idents feature, not anything
in the stable language. There is a footnote noting as such, and saying that
the situation is expected to improve soon, but this feature gate has existed
since before 1.0 and AFAIK no RFC has ever been written to describe this
feature, so this footnote gives a false sense of optimism. Furthermore, as per
the discussion at [https://github.com/rust-
lang/rust/issues/28979](https://github.com/rust-lang/rust/issues/28979) , it's
very unclear whether or not the stable form of this feature will end up using
XID_start or XID_continue. My fix is [https://github.com/rust-
lang/rust/pull/50790](https://github.com/rust-lang/rust/pull/50790).

In the same section on Special Unicode Productions, it defines the non_null
character class as any Unicode character but null, and then the non_eol
character class as any non_null character except for newline. Below it then
defines a grammar for line comments as two forward-slashes followed by zero or
more non_eol characters. But this is incorrect, because Rust does allow null
characters in comments: I don't expect that a code example will survive
network transmission, but modify the following program by replacing $ with a
null to see that it only prints "2", not "1\n2":

    
    
        fn main() {
            // test $ println!("1");
            println!("2");
        }
    

I doubt that this is a bug in rustc, because Go, which like Rust also mandates
UTF-8 source files, considers newline to be the only way to terminate a line
comment and AFAIK has no issues with accepting nulls. We also allow other
nonprinting characters in comments. This same error exists for the classes
concerning what is valid in char and string literals. My fix is
[https://github.com/rust-lang/rust/pull/50791](https://github.com/rust-
lang/rust/pull/50791).

Going back to the Notation page, the next paragraph has links to the sections
on unary and binary operators. The section on the dereference operator has a
typo: "variance" should be "variable". The section on the question mark
operator has the typo "errornous". The operator table should have a footnote
specifying that integer division rounds toward zero (as opposed to applying a
floor function, e.g.
[http://mathworld.wolfram.com/IntegerDivision.html](http://mathworld.wolfram.com/IntegerDivision.html)).
(Given the existing footnotes specifying the behavior of the right-shift
operator, I assume this is the proper place for this.) Further down, the
section on type casts is incomplete; the coercion table misses that non-
capturing closures can be cast to function pointers. The section on assignment
expressions should note that assignment expressions evaluate to (). Fixes at
[https://github.com/rust-lang-
nursery/reference/pull/337](https://github.com/rust-lang-
nursery/reference/pull/337).

The Notations page links to a section on tokens. The Characters and strings
table has a column labeled "# sets" that uses notation like "0...", which
should have a footnote for clarification. The section on Character escapes
refers to the previously-defined term "7-bit character code" as an "8-bit code
point escape". In the section on Byte and byte string literals, the grammar
definitions for ASCII_FOR_CHAR and ASCII_FOR_STRING exclude forward slashes,
when they should exclude backslashes. The section on invalid integer literals
says that overflowing literals are invalid, but they're not (this one is
arguably something that ought to be changed, and I've opened
[https://github.com/rust-lang/rfcs/pull/2438](https://github.com/rust-
lang/rfcs/pull/2438) to discuss changing it). The section on valid integer
suffixes omits the new 128-bit types. Fixes at [https://github.com/rust-lang-
nursery/reference/pull/338](https://github.com/rust-lang-
nursery/reference/pull/338) for these.

That covers all pages reachable from the first two paragraphs of the reference
and notes all the errors that are obvious to me in a single pass. I don't
intend this as a disparagement of the documenters--language references are
_damn hard_. There's surely plenty that I've overlooked. The degree of detail
is overwhelming and the inherent authority of the word "reference" means that
stakes are high. Compared to our other stellar docs the reference is notably
lacking, and releasing it alongside them is an outlier from our usual standard
of quality. Several large concepts are missing (such as, AFAICT, the type
inference algorithm); the section on unsafety may even (if I'm properly
interpreting the mood of the members of the unsafe code guidelines working
group) be verging on misleadingly dangerous (suffice to say I think the
Nomicon should be nightly-only as well (which is also not intended as a
disparagement of Gankro's efforts)). The fact that people are still
interpreting the reference so authoritatively suggests that more steps could
be taken to reduce confusion. At the very least I think it should moved to
nightly-only (and likewise remove its mention from www.rust-lang.org)... and
maybe also add one of these:
[http://images.mentalfloss.com/sites/default/files/styles/ins...](http://images.mentalfloss.com/sites/default/files/styles/insert_main_wide_image/public/under%20construction1_0.gif)
:)

I apologize for the phrase "unprincipled dumping ground", it was a rash way of
saying that the reference is developed in an ad-hoc way where sections are
(mostly) added or improved without apparent overarching guidance or large-
scale vision, hence all the missing pieces and parts that still date back to
1.0. I also apologize for suggesting that it ought to have been deleted; I
still harbor a latent prejudice against the reference for all the years where
it existed without anybody noticing that multiplication's precedence was
specified as somewhere between addition and subtraction. :)

~~~
steveklabnik
> It is the minimally-charitable interpretation of my statement to assume that
> I'm trying to disparage the people behind the reference.

An "unprincipled dumping ground" says something about those who are
maintaining it. It's not about charitable interpretations, it's about the
contents of what you said.

> I apologize

Thank you. But...

> I still harbor a latent prejudice against the reference

That you do things like this perpetuates the situation you complain about.
You're involved with the Rust project; to see you say things like this has
even more weight than some random person. Furthermore, to say the things that
you've said also demonstrates that you don't actually know what's going on
with the reference, making it extra frustrating.

Please reconsider your actions here. They only hurt, not help.

> That covers all pages...

Thank you! All of these things would make _great_ bugs, and I know you know
where to file them. Doing so would be a _tremendous_ help, and is exactly what
we need to make the reference better. That's what we need more of, not
disparaging it and those who work on it in front of thousands of people.

------
runevault
Having finally gotten back to rust after one false start (using it for the
Synacor Challenge), I'm glad to see it continue to flourish.

