Cohen: gccrs: An alternative compiler for Rust

> C wants to be the best low-level language on the largest supercomputers to small microprocessors where Linux is too big to run. You can't do that if there's one implementation that everyone has to follow.

That conclusion makes no sense.

>C wants to be the best low-level language

Thanks. That made my day.

>on the largest supercomputers to small microprocessors where Linux is too big to run.
>You can't do that if there's one implementation that everyone has to follow.

yet, Rust does it successfully.

> Can't you copy Rust "Editions"

There was a good blog post on this which I can't find due to search engine shittification, but the summary is no, or at least not easily.

But from memory, one reason is textual includes, macros and templates, which need to continue to work for backwards compatibility, and make it very ambiguous what edition to use for what code. Modules improve this somewhat nut there's still some issues, I don't remember the details. Another is the small compilation unit size combined with C++'s stable ABI, which makes it very hard to attain any benefits. A further problem is that cargo usually being able to instantly upgrade your source code without breaking anything is an essential part of what makes edition changes seamless in Rust, which is much more difficult in C++ both because it's harder to refactor automatically and no official organizational capacity exists to write such a tool. Then there's the issue that even in Rust, edition changes are limited to relatively simple syntax tree rewrites and stuff like turning warnings into errors. This still enables one to do a lot, but only in combination with other language features, which doesn't apply cleanly to C++ and would need to be rethought.

So it definitely could be done, but it's far more difficult, and more importantly there's mo obvious path towards the kind of improvements people want from C++ using this approach, compared to the effort it would require.

> Provided you can get people to agree on your prime implementation - always a big ask! - just bundle all the features you're getting rid of behind a "--deprecated-" flag.

This effectively already exists in the form of the various warnings compilers emit, but those are not standardized of course and wouldn't be enough anyway. But as you say, the real problem is getting a very broad consensus for something like this in an organizational structure where consensus is difficult to obtain, because it's just not the way things are done by default.

Rust's editions are essentially different "spellings" of the same language. For example, one edition can reserve a keyword while another edition lets it be an identifier. But the underlying language that is being accessed is the same (e.g., a type cannot implement a trait based on the compiled edition as "does X impl T?" needs to be the same regardless of the querying context's edition). The problem with adapting this to C++ is that the specific spelling can be part of the API contract. For example, templates are essentially macros at some level in that they are not checked for correctness until instantiation is attempted and the specific spelling used can matter quite a bit. Couple this with SFINAE[1] where one can ask "is this template instantiation valid?" and change behavior based on the answer, the set of things that one can actually change under such a C++ edition is minuscule.

At least that's my understanding of being in the room when the initial "let's bring editions to C++" paper was presented; I don't think things have changed much since then on that front.

Note that profiles uses a similar technique, but it works instead by *banning* the use of various spellings rather than allowing new spellings to have new meanings.

[1] https://en.wikipedia.org/wiki/SFINAE