
What If C++ Abandoned Backward Compatibility? - ingve
https://robert.ocallahan.org/2020/03/what-if-c-abandoned-backward.html
======
beefhash
Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that
isn't actually C++ but it's called C++ with a different version number and
people will then bicker for a few years until they realize that the "new" C++
isn't actually C++ and that the "old" C++ just vehemently refuses to die, so
they name it something else.

The C++ standards committee can standardize a backwards-incompatible "new" C++
for all I care as long as they don't call it C++.

~~~
eternalny1
I believe it's called Rust :)

~~~
The_rationalist
Sadly rust lack some big features that c++ has like polymorphic inheritance,
function overriding and function overloading.

~~~
SaxonRobber
I think that is for the best. I prefer less implicit behaviour in my code,
even if it means my identifiers get longer.

~~~
NotCamelCase
Rust doesn't have function/operator overloading _yet_ or it won't have it at
all? I am vastly for clarity and simplicity over vague, implicit stuff but
doing e.g vector operations can get very unreadable very quickly without it.

~~~
pjmlp
Rust has operator overloading,

[https://doc.rust-lang.org/rust-by-example/trait/ops.html](https://doc.rust-
lang.org/rust-by-example/trait/ops.html)

------
badsectoracula
It'll most likely be abandoned in droves. One of the main reasons to stick
with C++ (and C) is that the investment you put in the code you're writing
right now, no matter how fugly it is, will be there and keep working in the
future.

Also:

> I think it also makes sense for C++ developers whose projects are relatively
> short-lived, e.g. some games.

There is a difference between games and engines - the games might be short
lived, but most C++ engines are _very_ long lived, going back decades (e.g.
see how the recent Half-Life Alyx can trace its codebase back to Quake 1 or
pretty much anything based on the Unreal Engine going back to the mid-90s -
there are screenshots of UE1 running on what appears to be either Windows 3.1
or NT 3.51). Even when "engines" are being made "from scratch" this is often a
marketing gimmick and the "from scratch" was just renaming the engine because
it got a new rendering model and people can't tell the difference. _EVEN_ when
this isn't case, often new engines are based on existing code and/or
libraries.

~~~
bruxis
Agreed, I think looking at the Python 2 and 3 migration catastrophe gives a
glimpse into what this could look like, but I imagine it would be much worse
given the types of (large) projects that are backed by substantially "dated"
C/C++ code.

~~~
BiteCode_dev
The reasons the transitions worked were that:

\- the languages were not that different, so no need to learn the new version

\- python core devs gave 10 years to make the transition. Then extended it.

\- it was possible to write code running on python 2 and 3

\- python is very expressive, hence the code base have way less numbers of
lines than in C++

\- python cared only about one implementation, Cpython. The rest of the world
needed to follow. Some didn't, like Jython and stackless, and the community
didn't blink.

Despite all that, the transition was very painful.

~~~
ComputerGuru
“Worked?” Nothing about the Python 2 to 3 transition “worked” and people are
still aghast that’s Python 2 is being EOL’d.

~~~
BiteCode_dev
I've been coding in Python for 15 years, and from what I see in the numerous
places I get to work, yes, it worked.

It's just that aghast people are the most vocal. You don't hear the 90% of
people that are happy. They don't take the time to speak up. But the unhappy
complain all the time.

~~~
ComputerGuru
I’m not speaking about developers complaining, I’m speaking about the fact
that it’s still a fractured ecosystem and plenty of popular programs,
packages, and scripts still in use or even still actively developed rely on or
integrate with Python 2 (exclusively).

~~~
joshuamorton
> I’m not speaking about developers complaining, I’m speaking about the fact
> that it’s still a fractured ecosystem and plenty of popular programs,
> packages, and scripts still in use or even still actively developed rely on
> or integrate with Python 2 (exclusively).

Such as? What actively developed tools or ecosystems rely or integrate with
python2 exclusively?

------
vbezhenar
If C++ abandoned backward compatibility, then this C+++ would compete with
modern languages like D, Rust and it's absolutely not clear what the winner
would be. As long as C++ is backwards compatible, it have tremendous advantage
of having billions of LoC which don't have to be rewritten.

~~~
pjmlp
Like all systems languages, the winner would be those that are sponsored by OS
vendors for their platforms.

------
lytigas
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](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.

~~~
simias
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).

~~~
steveklabnik
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".

------
hedora
Sometimes I wish Google would just stop participating in open source and
standardization. The proposal actually suggests supporting Fuschia at the
language level, but not any of the BSDs, and replacing the ABI with protobuf
(or similar).

Much of this proposal would create insurmountable engineering problems for
everything except the Google monorepo, or similar infrastructure at $1T
companies building monoliths.

Historically, most innovation has happened outside of those environments.

Sabotaging the toolchains of smaller shops is not going to pan out well for
the industry at large.

~~~
google234123
They list an "initial non-exhaustive list of platforms" which includes
"OS/kernel." I don't think it's fair to say that they are excluding the BSDs
even if they aren't explicitly mentioned. The point is that new C++ shouldn't
need to support old and historical platforms.

------
gurkendoktor
Many people don't realize just _how_ conservative C++ is (the OP only briefly
mentions this). The committee not only avoids breaking existing source code,
but even _binaries_ , although binary compatibility is not defined in the
standard at all.

C++ 11, 14, 17, 20, and 23 are all binary compatible (modulo some possible
oversights). There are many quality-of-life improvements that got voted out
because then a binary compiled in C++11 wouldn't be compatible with one built
in C++23 anymore.

As a simple example ([1] has many more): the only reason we have both
std::scoped_lock and std::lock_guard is because changing the definition of the
latter would have required re-compilation of existing code, so a new class had
to be introduced.

ABI stability even overrides performance in committee decisions (see the
std::regex example, but I also heard it affects the footprint of unique_ptr -
edit: found it [2]).

tl;dr breaking source code compatibility seems way off if implementors don't
even dare to break binary compatibility.

[1] [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p202...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf)

~~~
snovv_crash
At this point they should just standardize the ABI. It would solve so many
headaches, and allow C++ to be used as a proper systems language.

~~~
pjmlp
In Windows we at least have COM and now UWP.

------
jefftk
Reading the paper that this is responding to is helpful if you want to get a
better understanding of the proposal and the motivation behind it:
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p213...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html)

~~~
santamarias
is there a discussion thread around that proposal somewhere?

~~~
jefftk
You're reading one ;)

------
ncmncm
There would then be two C++ languages. The overwhelming majority of users
would stick with the old one, a scant few would take up the new one, and the
rest would move on to some other language.

~~~
rumanator
This.

I'm currently working on a C++ project that has been taken out of cold storage
and when the old rewrite question pops up the tech stacks considered for the
job do not feature C++ at all. The main reason is that nowadays there are
better tools and frameworks to implement non-performance critical parts of an
application such as the GUI, which incidental takes over more than half the
total lines of code, and the rest can be implemented easily with small support
services developed in whichever tech stack you choose. Thus C++'s "jack of all
trades" trait is no longer a major factor in the decision. Meanwhile the lack
of a stable ABI starts to feature prominently as a reason not to adopt C++.

~~~
ncmncm
Most of the pressure to break compatibility comes from Microsoft and Google,
representing a truly minuscule fraction of C++ users. However, both are
heavily represented on the ISO Standard committee, and very, very little
happens there without their express approval.

Introducing a new ABI in competition with the current ones (e.g. ia32 and x64)
would be less destructive than officially abandoning those currently in use.

------
glouwbug
Isn't C++'s selling point that it is compatible with almost 45 years of code?

Seems like a terrible thing to break this late

------
Too
For this to work you would need stable bridge for calling between old and new
version, and with c++ lacking stable ABI and high dependency to header-
template interfaces (which is part of the bad c++ one would want deprecated),
this could be an issue. Sure, extern C already exists but it's a leaky
abstraction and it won't be added to existing libraries overnight. Without
this you can look at python 2 to 3 migration to see what will happen.

------
AllanHoustonSt
I personally wouldn’t mind seeing the language go the “editions” route a la
Rust.

~~~
steveklabnik
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p188...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2020/p1881r1.html)

~~~
AllanHoustonSt
I remember seeing murmurings of this on reddit. Cool to see it’s a paper now,
thanks for sharing.

------
olafure
The catastrophe would be worthy of inclusion in Randall Monroe's What If?
book.

------
hawski
It would be nice to have a compiler option, that would deprecate things from
earlier standards, that would work per file or per pragma block.

------
amelius
You would get D ...

~~~
ComputerGuru
You would get a runtime and GC?

~~~
AH2mdte8kPnJS
D is able to run without its runtime and GC.
[https://dlang.org/spec/betterc.html](https://dlang.org/spec/betterc.html)

And an older link:

[https://www.auburnsounds.com/blog/2016-11-10_Running-D-
witho...](https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-
runtime.html)

~~~
roca
Able to run, yes. But it is not the default, ergonomic way to write D code
like it is in C, C++ and Rust.

~~~
pjmlp
Thankfully, GC offers productivity and allows for safe code by default, while
D still offers the necessary language features to do all the low level tricks
from C, C++, Rust, Objective-C, if one actually needs to go down that level.

~~~
roca
I like being able to write safe _and_ GC-free code by default. Rust would be
even better if it was possible to opt into GC, but I would still want to to be
GC-free by default. It's good that the entire library ecosystem has grown up
GC-free and that should continue.

------
SaxonRobber
I’ll never understand the portion of the C++ community that insists on
modernizing the language to the detriment of everything else. When is enough
enough? Just let the language be and focus on improving the standard library,
not changing language features.

~~~
google234123
You do realized that the standard library is also specified? You can't change
bad things in the std without breaking backward compatibility.

~~~
SaxonRobber
I mean standardizing libraries that are widely useful for minimizing external
dependencies.

Like networking support, serialization for ubiquitous formats like JSON, etc.

------
protomyth
So, the author wants something between FORTRAN's Ratfor and F. I can see it as
a supplement to the C++ standard but not being the actual standard. It would
make people distrust C++ greatly if implemented as the standard.

------
alpineidyll3
It'd def. be better to lay it next to COBOL in Valhalla and move on. Breaking
the Bkwds comp. makes it C++ in name only.

------
gameswithgo
it would be rust

------
gigatexal
It’d probably be 20% as big

------
ImprovedSilence
It would become Rust?

------
santamarias
I think this discussion is awesome, such a readworthy mix of opinions,
experience and large scale digressions :)

------
api
You'd get Rust or maybe something in between Rust and Go. We have Rust and Go,
so there's no point.

~~~
throwaway17_17
I don’t see how you can draw this conclusion. Taking C++ and breaking backward
comparability just means you can move the standard for C++ foreword without
concern for supporting 10+ year old source code. I cannot see a reason this
would impose some stringent, immutable by default ownership/borrowing
requirement, a radically different type system, a lose of template meta
programming for macros (in the case of Rust) or the adding of garbage
collection and an invasive runtime with a language imposed concurrency model
to the exclusion of others (in the case of Go).

Sure as time passed, the non backward compatible C++ would add features not
currently in scope for C++, but the radical redesign of the fundamental
language is not what this proposal suggests.

~~~
wvenable
> I don’t see how you can draw this conclusion.

Those two languages were created without consideration of backwards
compatibility with C/C++ source code and were designed for the same job. It
stands to reason that given no constraints of compatibility, you'd get
something similar to those languages.

Now obviously, those languages do not have all the features of C++ nor the
same design principles. But as soon as you have all the features of C++ with
the same principles, you have something so close to C++, that it doesn't make
sense to break backwards compatibility.

------
jmakov
We have Python2, Python2.7 and Python3.x. Everybody happy. Loose backward
compatibility and evolve.

------
cbsmith
You mean, exactly like D?

------
mihaaly
It would become C# :)

~~~
felixguendling
I think the concept would look more like Rust. It is still compiled to machine
code, not VM opcode. You do not need a VM and do not require a garbage
collector, JIT, etc. which makes it suitable for more use cases.

But: if it's a completely new language (no backward compatibility to C++) -
why do we need this? Can't we just use one of those new languages that are
already available (Rust, Zig, Odin, Nim, just to name a few).

~~~
DangitBobby
Those languages are all pretty different from C++, right? I'm assuming the new
C++ would be very similar to old C++ with a bunch of things "considered
harmful" removed.

~~~
throwaway17_17
Well I’ve seen at least three recent CppCon talks where they say that ‘for’
loops are harmful and a template function should be used always, so I would
hope there would not be a removal of these things, just a non-concern with
requiring that changes don’t break the compilation of 10+ year old code.

------
himinlomax
Well we'll have to maintain the old version. It'd be simpler to keep on
calling it "C++," but then we need a catchier name for "new C++." How about
"Rust?"

