3 ms·

I think the idea of "when incompatible changes must me made" has caused much harm and damage to various language projects. I'm specifically thinking of the dama

by eej71 2y ago

I think the idea of "when incompatible changes must me made" has caused much harm and damage to various language projects. I'm specifically thinking of the damage done as part of the python 2->3 changes and to a lesser extent the damage done with the original conception of what was called perl6. C++ is definitely in a tough spot on the evolutionary trail. But the idea that the only path ahead is through incompatible changes seems likely to produce the same harmful effects.

tialaramex 2y ago
In 2019 Epochs was proposed for C++. That's "too late" for C++ 20, but only by convention. Epochs proposed to give C++ a way to evolve while retaining better backward compatibility, much like Rust's Editions (the 2024 Edition stabilized last year and will ship in Rust 1.85 in a week or two) Instead C++ has added all sorts of slightly incompatible features every three years since 2011, and is expected to do so again, periodically one of these incompatible changes is especially troublesome for important people and, like a naughty toddler, the committee promises not to do that again. Yet, despite these incompatible changes which might have accidentally larger consequences than expected, for fear of the consequences other changes which were known to be incompatible but seem "worth it" are rejected. The worst of both worlds.
- pjmlp 2y ago
  In practice, epochs offer little more than -std=lang-version, because they only cover grammar changes, and a few selected semantics. There is no plan for binary libraries across epochs, how different implementations would interact with each other, how multiple crates requiring different versions would interact with each other if their public API crosses versions with different semantics,...
  - tialaramex 2y ago
    I'd argue that one of the things we saw with Rust's Editions is that it significantly increases appetite for such language improvements. There's a recent Reddit discussion which had zero pushback against changes but instead people who were disappointed that 2024 Edition won't land all the things they'd hoped for such as the improved Range types† Without the Edition system we know from C++ that when you say "Why can't we have X?" the defenders appear to tell you that all choices except the status quo are impossible. They will do this regardless of how difficult such a change would be, and so this immediately deflates all interest in incremental improvement. It's a self-fulfilling prophecy. But with Editions there's a lot of things we definitely can do. Once you open the door to that, it really drives enthusiasm and that enthusiasm can power some of the difficult changes you wouldn't even have considered in the C++ process. † In Rust syntax like 1..=4 is compiled into the core type core::ops::RangeInclusive<i32> so this is a very natural way to express what you meant, and yet it's not a goofy special case it's just a normal literal like "Word" [an &'static str] or '€' [a char] or 1.2345 [a floating point defaulting to f64] -- however, we now realise these range types made some poor choices and if you made them today you'd make them implement Copy and IntoIterator, whereas the existing types implement Iterator and so in many cases cannot implement Copy. Ergonomically a Copy type would be much nicer here. Can we fix that? Well, the idea is, we make the new types (they exist in nightly Rust in the new core::range namespace but aren't stabilized) and then once we're sure they're exactly what we want we make a new Edition which changes the syntax transformation so that that literal is a core::range::RangeInclusive<i32> instead.
pjmlp 2y ago
C++ already had quite a few incompatible changes, your C++98 code will not compile in a C++23 mode compiler, if lucky enough to use one of such features.
- eej71 2y ago
  Ok, so could we agree that then doubling down on even more breaking changes is likely to create more codebases stuck at these "evolutionary bottlenecks"? Whenever I hear someone say - "Gee, the only path ahead is a breaking change, sorry charlie!", what I really hear is - "I gave up thinking up a solution on how to do it an evolutionary way and I am lazy and just want to declare a revolution!". There is always a pathway ahead on the evolutionary path. That's the premise at least.
Doxin 2y ago
> I'm specifically thinking of the damage done as part of the python 2->3 changes Though on the other hand, we can only the imagine of not doing those changes. I reckon it would be at least as bad as the 2->3 changes. At the very least I wouldn't want to go back to a world where bytes and strings were unified.

by eej71 2y ago

tialaramex 2y ago

In 2019 Epochs was proposed for C++. That's "too late" for C++ 20, but only by convention. Epochs proposed to give C++ a way to evolve while retaining better backward compatibility, much like Rust's Editions (the 2024 Edition stabilized last year and will ship in Rust 1.85 in a week or two) Instead C++ has added all sorts of slightly incompatible features every three years since 2011, and is expected to do so again, periodically one of these incompatible changes is especially troublesome for important people and, like a naughty toddler, the committee promises not to do that again. Yet, despite these incompatible changes which might have accidentally larger consequences than expected, for fear of the consequences other changes which were known to be incompatible but seem "worth it" are rejected. The worst of both worlds.

pjmlp 2y ago
In practice, epochs offer little more than -std=lang-version, because they only cover grammar changes, and a few selected semantics. There is no plan for binary libraries across epochs, how different implementations would interact with each other, how multiple crates requiring different versions would interact with each other if their public API crosses versions with different semantics,...
- tialaramex 2y ago
  I'd argue that one of the things we saw with Rust's Editions is that it significantly increases appetite for such language improvements. There's a recent Reddit discussion which had zero pushback against changes but instead people who were disappointed that 2024 Edition won't land all the things they'd hoped for such as the improved Range types† Without the Edition system we know from C++ that when you say "Why can't we have X?" the defenders appear to tell you that all choices except the status quo are impossible. They will do this regardless of how difficult such a change would be, and so this immediately deflates all interest in incremental improvement. It's a self-fulfilling prophecy. But with Editions there's a lot of things we definitely can do. Once you open the door to that, it really drives enthusiasm and that enthusiasm can power some of the difficult changes you wouldn't even have considered in the C++ process. † In Rust syntax like 1..=4 is compiled into the core type core::ops::RangeInclusive<i32> so this is a very natural way to express what you meant, and yet it's not a goofy special case it's just a normal literal like "Word" [an &'static str] or '€' [a char] or 1.2345 [a floating point defaulting to f64] -- however, we now realise these range types made some poor choices and if you made them today you'd make them implement Copy and IntoIterator, whereas the existing types implement Iterator and so in many cases cannot implement Copy. Ergonomically a Copy type would be much nicer here. Can we fix that? Well, the idea is, we make the new types (they exist in nightly Rust in the new core::range namespace but aren't stabilized) and then once we're sure they're exactly what we want we make a new Edition which changes the syntax transformation so that that literal is a core::range::RangeInclusive<i32> instead.

pjmlp 2y ago

C++ already had quite a few incompatible changes, your C++98 code will not compile in a C++23 mode compiler, if lucky enough to use one of such features.

eej71 2y ago
Ok, so could we agree that then doubling down on even more breaking changes is likely to create more codebases stuck at these "evolutionary bottlenecks"? Whenever I hear someone say - "Gee, the only path ahead is a breaking change, sorry charlie!", what I really hear is - "I gave up thinking up a solution on how to do it an evolutionary way and I am lazy and just want to declare a revolution!". There is always a pathway ahead on the evolutionary path. That's the premise at least.

Doxin 2y ago

> I'm specifically thinking of the damage done as part of the python 2->3 changes Though on the other hand, we can only the imagine of not doing those changes. I reckon it would be at least as bad as the 2->3 changes. At the very least I wouldn't want to go back to a world where bytes and strings were unified.