Idea: "language warts" RFC repo

[illustrious-you]

That’s why I’d love to hear some statement on how large changes can be between major versions of Rust. It would be a disappointment if they were comparable to changes in minor versions. If you have a hard limit on the size of fixes, broken things just start piling up until the language collapses under its own complexity.

Thus far, the impression I’ve gathered from the core team is that a major version hasn’t been contemplated in any serious manner. If it were to occur, the scale of changes accpeted in a major version would be determined like everything else–through community discussion, RFC development, and consensus among the Rust teams. Organizing and discussing the language warts is the first step along a journey that won’t bear fruit until at least the next edition (and likely longer). It’s too early to know if there should be a “Rust 2.0”, much less delimit what it may include.

[Centril]

There will never be a Rust 2.0.

[ExpHP]

I don’t know what the language of the year 2050 will look like, but I know it won’t be called Rust 2.0.

— Tony Hoare, 1982

[Ixrec]

To clarify for those less familiar with past discussions:

Although the editions RFC does not explicitly state “there will never be a Rust 2.0” (in the sense of a breaking change that, unlike editions, offers no interoperability between pre-2.0 and post-2.0 crates), it was almost universally interpreted that way (for example, this comment), and the stability commitment that implied was one of the proposal’s huge benefits, and I believe the acceptance of the RFC does indicate a commitment to never having a Rust 2.0 in the above sense. I think something truly catastrophic would have to happen to Rust to make us seriously consider a 2.0 now.

[madmalik]

I think we should explicitly separate two different categories here:

• language warts that are just plain bad/annoying/made the wrong trade offs and may or may not be fixed
• lessons learnt from the design of the rust programming language that could inform the design of other programming languages

If we were a long while before 1.0 i’d “vote” for [] instead of <> for types. But a change that impacts nearly every single line of rust code ever written… nah, won’t happen.

It’s good to think about it nonetheless, but it’s a different concern than a repository of small nitpicks than have the chance of being fixed.

[felix91gr]

If we’re going to have operators tied to semantics, under a consistent Trait system for them we could help code readability because the kind of operator you’re seeing would be associated with certain properties. Taking the idea from @leonardo here:

I prefer + to be used for commutative operations

These are some ideas that gives me: [square brackets are optional restrictions that I think could also make sense]

• +: commutative (and associative) operation [on a group, also defines an inverse - and so on like described here].
• ~ associative operation, as the one in a semigroup. These semantics are the ones of string concatenation.
• * defined with similar semantics as +.
• (example) # associative, invertible operation over a group, such as the one defined by square invertible matrices and quaternions.

More operators of this kind could be defined, probably. Which ones am I missing? Probably at least 3

Operators that give boolean results can be seen as binary relations. This allows us to define semantics for such relations:

• = is reflexive, symmetric and transitive. This means it defines an Equality Class (trait Eq)
• <= is reflexive, antisymmetric and transitive. It defines a Partial Order (trait PartialOrd)
• < means a<b <=> a<=b && !a=b

There are some operations mentioned in other posts that work over e.g. a vectorized input: Vec<f32> x Vec<f32> -> Vec<bool>. I don’t know how the semantics of such operations reflect into algebra, so I’ll need help there . I’m sure there is a general concept behind them

[newpavlov]

+ : commutative (and associative) operation

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

[illustrious-you]

There will never be a Rust 2.0.

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

I think something truly catastrophic would have to happen to Rust to make us seriously consider a 2.0 now.

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.

[Ixrec]

There will never be a Rust 2.0.

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

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.

[scottmcm]

+ : commutative (and associative) operation [on a group, also defines an inverse - and so on like described here].

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

[felix91gr]

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.

[uberjay]

Yeuch. For the purposes of feeling “heavy,” I consider camel case to be many times more fearsome, because for certain letter combinations, every time I type them there’s a chance of it coming out DoubleUPpercase , which is one of the most brutally annoying mistakes to have to fix.

(Ironically, this almost never happens to me with underscores, even though they require shift on an American keyboard, because their location on the top row slows me down just enough to ensure that I release shift. I suspect that somebody with an Italian layout might have some choice words for me…)

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

[Centril]

There will never be a Rust 2.0.

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.

[system]

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