12 ms·

Something that Rust got _really_ right: Editions. And not just that they exist, but that they are specified per module, and you can mix and match modules with

Something that Rust got _really_ right: Editions. And not just that they exist, but that they are specified per module, and you can mix and match modules with different Editions within a bigger project. This lets a language make backwards incompatible changes, and projects can adopt the new features piecemeal. If such a thing came to C++, there would obviously be limitations around module boundaries, when different modules used a different Edition. But perhaps this could be a way forward that could allow both camps to have their cake and eat it too. Imagine a world where the main difference between Python 2 and 3 was the frontend syntax parser, and each module could specifically which syntax ("Edition") it used...

steveklabnik 2y ago
There was a similar proposal for C++, using rust’s original names: epochs. It stalled out.
- ykonstant 2y ago
  They should call them 'eras'. Then they can explain that epochs did not lead to a new era in the language, but eras will mark the next epoch of C++.
CrendKing 2y ago
But Edition can exist only because Rust intrinsically has the concept of package, which naturally defines the boundary. C++ has nothing. How do you denote a.cpp be of cpp_2017 edition which b.cpp be cpp_2026? Some per-file comment line at top of each file? C++ is a mess in that it has too much historic baggage while trying to adapt to a fiercely changing landscape. Like the article says, it has to make drastic changes to keep up, but such changes will probably kill 80% of its target audiences. I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go. It is time to either switch to Rust, or pick one of its successor languages and put effort into it.
- hypeatei 2y ago
  > I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go I agree but also understand this is absolutely wishful thinking. There is so much inertia and natural resistance to change that C++ will be around for the next century barring nuclear armageddon.
  - adgjlsfhk1 2y ago
    Cobol's still around. Just because a language exists doesn't mean that we have to keep releasing updated specifications and compiler versions rather than moving all those resources to better languages.
    - AnimalMuppet 2y ago
      COBOL's most recent standard was released in 2023, which rather ruins your point.
      - tialaramex 2y ago
        I think the existence of COBOL-2023 actually suggests that it's not merely possible that in effect C++ 26 is the last C++ but that maybe C++ 17 was (in the same sense) already the last C++ and we just didn't know it. After all doubtless COBOL's proponents did not regard COBOL-85 as the last COBOL - from their point of view COBOL-2002 was just a somewhat delayed further revision of the language that people had previously overlooked, surely now things were back on track. But in practice yeah, by the time of COBOL-2002 that's a dead language.
        pjmlp 2y ago
        Fully agree, because for the use cases of being a safer C, and keeping stuff like LLVM and GCC running, that is already good enough. From my point of view C++26 is going to be the last one that actually matters, because too many are looking forward to whatever reflection support it can provide, otherwise that would be C++23. There is also the whole issue that past C++17, all compilers seem like a swiss cheese in language support for the two following language revisions.
SkiFire13 2y ago
> And not just that they exist, but that they are specified per module Nitpick: editions are specified per crate, not per module. --- Also note that editions allow to make mostly syntactic changes (add/remove syntax or change the meaning of existing ones), however it is greatly limited in what can be changed in the standard library because ultimately that is a crate dependency shared by all other crates.
wink 2y ago
My C++ knowledge is pretty weak in this regard but couldn't you link different compilation units together just like you link shared libraries? I mean it sounds like a nightmare from a layout-my-code perspective, but dumb analogy: foo/a/* is compiled as C++11 code and foo/b/ is compiled as C++20 code and foo/bin/ uses both? (Not fun to use.. but possible?) Is that an ABI thing? I thought all versions up to and including C++23 were ABI compatible.
- zozbot234 2y ago
  How does foo/bin use both when foo/a/* and foo/b/ use ABI-incompatible versions of stdlib types, perhaps in their public interfaces? This can easily lead to breakage in interop across foo/a/* and foo/b/ .
  - layer8 2y ago
    How does Rust do it?
    - deleted 2y ago
      [deleted]
    - GolDDranks 2y ago
      By linking both and not allowing mixing types, i.e. it considers types from a totally unrelated with types from b. Also, Rust compiles the whole world at once, so any ABI breakage from mixing code from different compiler versions doesn't happen. (Editions are different thing from compiler versions, a single version of the compiler supports multiple editions.)
      - steveklabnik 2y ago
        Rust does not compile the whole world at once. Each crate is compiled separately, and then they’re all linked together at the end.
        2y ago
humanrebar 2y ago
The C++ profiles proposal is something like an "editions lite". It could evolve into more fully featured editions some day, though not without some significant tooling work to support prevention of severe memory and type safety issues across different projects linked into the same program.
kccqzy 2y ago
That's irrelevant. Look, the C++ committee has decided yet again not to break ABI. That is to say, they have affirmed that they DO NOT want backwards incompatible changes. So suggesting a way to make backwards incompatible changes is of no interest to the C++ committee. They don't want it and they have said so more than once.

steveklabnik 2y ago

There was a similar proposal for C++, using rust’s original names: epochs. It stalled out.

ykonstant 2y ago
They should call them 'eras'. Then they can explain that epochs did not lead to a new era in the language, but eras will mark the next epoch of C++.

CrendKing 2y ago

But Edition can exist only because Rust intrinsically has the concept of package, which naturally defines the boundary. C++ has nothing. How do you denote a.cpp be of cpp_2017 edition which b.cpp be cpp_2026? Some per-file comment line at top of each file? C++ is a mess in that it has too much historic baggage while trying to adapt to a fiercely changing landscape. Like the article says, it has to make drastic changes to keep up, but such changes will probably kill 80% of its target audiences. I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go. It is time to either switch to Rust, or pick one of its successor languages and put effort into it.

hypeatei 2y ago
> I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go I agree but also understand this is absolutely wishful thinking. There is so much inertia and natural resistance to change that C++ will be around for the next century barring nuclear armageddon.
- adgjlsfhk1 2y ago
  Cobol's still around. Just because a language exists doesn't mean that we have to keep releasing updated specifications and compiler versions rather than moving all those resources to better languages.
  - AnimalMuppet 2y ago
    COBOL's most recent standard was released in 2023, which rather ruins your point.
    - tialaramex 2y ago
      I think the existence of COBOL-2023 actually suggests that it's not merely possible that in effect C++ 26 is the last C++ but that maybe C++ 17 was (in the same sense) already the last C++ and we just didn't know it. After all doubtless COBOL's proponents did not regard COBOL-85 as the last COBOL - from their point of view COBOL-2002 was just a somewhat delayed further revision of the language that people had previously overlooked, surely now things were back on track. But in practice yeah, by the time of COBOL-2002 that's a dead language.
      - pjmlp 2y ago
        Fully agree, because for the use cases of being a safer C, and keeping stuff like LLVM and GCC running, that is already good enough. From my point of view C++26 is going to be the last one that actually matters, because too many are looking forward to whatever reflection support it can provide, otherwise that would be C++23. There is also the whole issue that past C++17, all compilers seem like a swiss cheese in language support for the two following language revisions.

SkiFire13 2y ago

> And not just that they exist, but that they are specified per module Nitpick: editions are specified per crate, not per module. --- Also note that editions allow to make mostly syntactic changes (add/remove syntax or change the meaning of existing ones), however it is greatly limited in what can be changed in the standard library because ultimately that is a crate dependency shared by all other crates.

wink 2y ago

My C++ knowledge is pretty weak in this regard but couldn't you link different compilation units together just like you link shared libraries? I mean it sounds like a nightmare from a layout-my-code perspective, but dumb analogy: foo/a/* is compiled as C++11 code and foo/b/ is compiled as C++20 code and foo/bin/ uses both? (Not fun to use.. but possible?) Is that an ABI thing? I thought all versions up to and including C++23 were ABI compatible.

zozbot234 2y ago
How does foo/bin use both when foo/a/* and foo/b/ use ABI-incompatible versions of stdlib types, perhaps in their public interfaces? This can easily lead to breakage in interop across foo/a/* and foo/b/ .
- layer8 2y ago
  How does Rust do it?
  - deleted 2y ago
    [deleted]
  - GolDDranks 2y ago
    By linking both and not allowing mixing types, i.e. it considers types from a totally unrelated with types from b. Also, Rust compiles the whole world at once, so any ABI breakage from mixing code from different compiler versions doesn't happen. (Editions are different thing from compiler versions, a single version of the compiler supports multiple editions.)
    - steveklabnik 2y ago
      Rust does not compile the whole world at once. Each crate is compiled separately, and then they’re all linked together at the end.
      - 2y ago

humanrebar 2y ago

The C++ profiles proposal is something like an "editions lite". It could evolve into more fully featured editions some day, though not without some significant tooling work to support prevention of severe memory and type safety issues across different projects linked into the same program.

kccqzy 2y ago

That's irrelevant. Look, the C++ committee has decided yet again not to break ABI. That is to say, they have affirmed that they DO NOT want backwards incompatible changes. So suggesting a way to make backwards incompatible changes is of no interest to the C++ committee. They don't want it and they have said so more than once.