Hacker News Reader

Comment by lytigas | Hacker News Reader

Some here are saying "Why not just use Rust/D/Zig/Nim/Crystal if you're going to break backwards compatibility?" I believe the proposal is closer to "We've removed this old feature, run this tool to replace it with the new one." C++ will keep looking like C++, not like Rust. Here's Google's "Codebase Cultivator" explaining the idea for their Abseil library:

https://youtu.be/tISy7EJQPzI?t=2209

I remember watching another talk where they propose something similar for the language itself, but I can't find it at the moment.

View on HN

This.

Per Hyrum's law, someone will rely on any given behavior. So, if you choose backwards compatibility, it becomes harder for the committee to evolve the language over time.

The path of breaking changes can be made less painful, and does not, necessarily, invalidate all the code that is already written.

With that being said, the problem right now is not the decision of keeping backwards compatibility or not, but the fact that the standard should be explicit about it, so people know what to expect.

Yeah there's a lot of discussion here as if the proposal is some radical breaking thing when in reality it's stupid stuff like "stop pretending a byte isn't always 8-bits" or "if you're a platform that's still shipping a 10 year old compiler, you're not supported anymore in the latest language version." Problems that you'd never even dream of in most other languages.

Because C++ is not a single implementation language, rather driven by a standard with multiple implementations.

Such a solution is only possible if driven by the standard, otherwise it will never be fully available, just like the static analysis tooling varies by vendor.

That sounds worryingly close to the JavaScript model.

Unless you manage to integrate this directly into the compiler stack and have it work 100% of the time with no "ifs" or "buts" I don't think it'll work.

Maybe you could do like Rust with their "Epoch" system that lets you interoperate code using various standards in order to migrate progressively without breaking backward compatibility. I suspect that it would be a lot harder to make it work for C++ however, mainly due to its extreme reliance on #includes (especially for anything using templates) and more common use of macros.

I'm not saying it's impossible but I suspect that it would fragment the ecosystem quite a bit. Removing "old features" tends to have massive side effects in a language like C++ with metaprograming, overloading, multiple inheritance, unlimited macro usage and complex symbol resolution rules.

So I think "why not just use Rust/D/Zig/Nim/Crystal" is warranted feedback for these proposals (and you could probably add Go, C#, Java and a few others).

Funny enough, Rust doesn't call them "epochs" anymore, we switched to "edition" before the release.

However, there's an active (and in my understanding, decently received) proposal based on it for C++ that is called "epochs".

Reply on news.ycombinator.com