3 ms·

Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this pro

Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this proposed that there should be a way for C++ to evolve, forbidding obsolete syntax in newer projects rather than just growing forever like cancer. Epochs was given the usual WG21 treatment and that's the end of that. Rust shipped 2021 Edition, and 2024 Edition, and I see no reason to think 2027 Edition won't happen. The current iteration of Bjarne's "Profiles" idea is in a similar ballpark though it got there via a very different route. This time because it will aid safety to outlaw things that are now considered a bad idea. If this goes anywhere its nearest ship vehicle is C++ 29. Now, Python 2 to Python 3 did take a few years, maybe a decade. But just shipping the mechanism to reform C++ looks likely to take at least nine years. Not the reform, just the mechanism to enable it.

pjmlp 10mo ago
Meanwhile editions still don't have an answer for semantics changes exposed on public APIs for crates, each compiled on its own edition. So what does the compiler chose, the edition of the caller, or the caller?
- tialaramex 10mo ago
  I don't understand the question, maybe you have an example?
  - pjmlp 10mo ago
    In general, even though semantic changes haven't yet been a thing in editions so far. Crate A uses edition X. Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way. Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal. So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about. Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
    - tialaramex 10mo ago
      OK, so you don't have any examples, I recommend coming back once you have an example as otherwise there's nothing concrete to engage with here.
      - pjmlp 10mo ago
        That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
    - simonask 10mo ago
      I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary. I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?

pjmlp 10mo ago

Meanwhile editions still don't have an answer for semantics changes exposed on public APIs for crates, each compiled on its own edition. So what does the compiler chose, the edition of the caller, or the caller?

tialaramex 10mo ago
I don't understand the question, maybe you have an example?
- pjmlp 10mo ago
  In general, even though semantic changes haven't yet been a thing in editions so far. Crate A uses edition X. Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way. Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal. So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about. Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
  - tialaramex 10mo ago
    OK, so you don't have any examples, I recommend coming back once you have an example as otherwise there's nothing concrete to engage with here.
    - pjmlp 10mo ago
      That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
  - simonask 10mo ago
    I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary. I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?