Idea: "language warts" RFC repo

Note that floating point addition is not necessarily associative due to roundoff errors, and strictly speaking if we'll consider NaNs even not commutative.

7 Likes

If that's truly the case, then the major version number is a wart.

I agree. I imagine that most warts would either be accepted during an edition change or closed because they would require "2.0" (effectively forking Rust). I can't imagine anything short of unsoundness in the lifetime/ownership system causing a "2.0" language change. That said, the direction of Rust is determined by a combination of community action and consensus among the leadership. Who's to say what the community will want, or what the leadership will think? Presuming that the anything about versioning policy one or more decades from now is an act of hubris.

Some relevant comments from the Editions RFC thread:

KiChjang commented on Jul 4, 2017 •

A slight tangent to this RFC: if we are not going to follow semver's version breaking changes and instead adopt epochs, should we just simply drop the "1.x" prefixes on rustc's versions?

EDIT: I think as a corollary to that, we should also ditch semver altogether and figure out what rustc's own versioning scheme should be.

golddranks commented on Jul 4, 2017

@kichang there is value in versioning the compiler separately from the language. One could say that the "1." part of the version number becomes futile if there's never going to be 2.0, but it still essentially communicates the intent, as it's a semver-based version number: "this compiler is still 1.x, and therefore still compatible with the good old Rust!"

SimonSapin commented on Jul 4, 2017 •

A slight tangent to this RFC: if we are not going to follow semver's version breaking changes and instead adopt epochs, should we just simply drop the "1.x" prefixes on rustc's versions?

Staying at 1.x.y forever is a valid use of SemVer. Also I think it helps signal to the outside world that we’re committed to stability.

I’ve said it when 1.0.0 came out and and I still think it: I’m looking forward to the release of Rust 1.100.0 as a proof that our stability story has worked.

hsivonen commented on Jul 6, 2017

...

Keeping rustc on the 1.X series in perpetuity provides clear messaging that upgrading the compiler, alone, does not entail breakage.

FWIW, I think the "1." prefix is a mistake, since it implies the possibility of Rust doing its Python 3 aka. Rust 2.0, and I think "Rust 2.0" showing up as a concept every now and then (including in this thread!) is harmful, since it creates doubt that Rust might do a Python 3 after all.

It's now too late to drop the "1." prefix, but marketing-wise, it would be good to do what Java did: commit to never doing Rust 2.0 and hide the "1." prefix from marketing and colloquial references to rustc versions.

...

Lokathor commented on Jul 25, 2017 •

...

As to versioning, we should stick with semvar only and with talking about things in terms of semvar instead of some alternate version scheme for marketing. We should not pull a Java and drop the 1. part of our version. Rust is good because we provide a good product and a good experience. Part of that product is the stability promise, and the longer we stay at 1.x as the only way we talk about our version, the stronger our stability promise becomes. If there's some breaking change that the language absolutely needs but that can't be done even with opt-in feature gates, then we can talk about a major version bump in that far future. That might not ever happen, or maybe it will. People can be as dedicated as they want to either camp, but try to remember that we're 2 years into the language's life and we're comparing ourselves to languages that are ten times or more as old as our language is. To claim that we fully understand how the next few decades of computing will unfold is kinda foolish. Until then, we are 1.x for as long as possible.

...

...and I think I'm gonna stop there. omg people have a lot to say about version numbers.

Personally, I don't have strong feelings either way, though it does seem like dropping the "1." would cause some problems and confusion (not just because we had a 1. to begin with) and doesn't really have much of a benefit.

3 Likes

Note that in debug mode, that would mean that even u32 can't use +, because there's no additive inverse for natural numbers.

4 Likes

Yeah, that’s why I put it in [square brackets]. Adding the Abelian Group properties is nice, but you restrict it too much. I guess that’s why std::ops has the trait Add separate from Neg. It’s a bit more cumbersome, but it allows for finer-grained design.

If you're an emacs user, you might enjoy smart-dash mode. Having now used it for >5 years, I can't imagine the number of keypresses it's saved me. Being able to avoid the shift key for large swaths of code is pretty wonderful. I haven't seen anyone put together a module like this for any other editor, but I suppose it should be possible, given sufficient customizability.

The only downside is you're going to end up accidentally typing dashes all over the place with other pieces of software. (the struggle is real!)

I want to apologize for my tone here! It came of as more brash than was intended. Sorry for that, and thank you to @Ixrec for giving a good explanation.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.