That's not the language ABI. This is the same term used for two different things. Language ABI is stuff like "this is how name mangling works", "this is how parameters are passed", and "this is the widest integer type."
I think it does. It also opens another big hole of worms of maintaining and porting the existing software. And it also opens another question which is: how often should we allow to break the ABI? On regular basis, semi-regular basis, rare, very rare etc. And who defines this threshold?
What do you think the reasons are that ABI transition didn't happen already?
"How often" is indeed a decent question, but the ranges aren't too wide. It'd either be once per C++ release (every couple of years) or in some of the C++ releases (every five years or so). It isn't like if the committee decides it is okay to increase the widest integer type every week.
The reasons why the ABI transition hasn't happened already is because C++ has a historical position of breaking the ABI only very very rarely. This is, in part, a legacy from a world where it really was going to be frustratingly difficult to get new builds of their libraries.
In an ideal world you would just need to "press a button". So this could happen every second day without any issue.
Of course things are more complex. Not everything is a Linux distribution where it's simple to rebuild the world.
But as the history of C++ shows people managed to life with this issue for a very long time. So it's not a show stopper in any way.
Even other very conservative languages like Java found a balance for breaking changes. The "problem" C++ has is more of a mental one, imho.
Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds. You could improve future version (or editions) but stay compatible to old ones at the same time.
Rebuilding trillions LoC that are deployed on literally every computer architecture, dozens of toolchains and OS's is a high impact and high risk problem with arguable benefits. Although it is technically possible, I don't think it is a process which "just happens" but it is a process which probably take years to be implemented on each and every platform.
So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.
> Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.
We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.
> Rebuilding trillions LoC that are deployed on literally every computer architecture, dozens of toolchains and OS's is a high impact and high risk problem with arguable benefits. Although it is technically possible, I don't think it is a process which "just happens" but it is a process which probably take years to be implemented on each and every platform.
It was mentioned already that Linux distributions are doing exactly this. On every major compiler update.
> So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.
Sure it's not trivial to set up. But it's possible and done so for a long time already.
Sure, things could be made simpler. For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)
> > Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.
> We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.
That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.
> It was mentioned already that Linux distributions are doing exactly this. On every major compiler update.
I guess you're aware not everything runs on Linux neither are all Linux deployments vanilla Linux deployments. At this point I think you're just intentionally ignorant or completely unaware of the world outside your bubble environment.
> For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)
Eh?
> That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.
It is an argument because suggesting to "easily introduce" the idea from another immature language which (1) is not proven and (2) which will take long long time before it does is wishful thinking, if not nonsense and far from reality. Rust "editions" do not solve the problem because, well, to begin with Rust doesn't have the problem of the same scale that C++ does.
We'll see what C++ will do in this regard but I wouldn't hold my breath. Disadvantages of breaking the ABI frequently currently outweigh the advantages and my opinion is that it will stay the same way for unforeseeable time.
> I really don't see how this can be considered as a reasonable thing to do […]
Well, Linux distributions do exactly this, since decades, and it works just fine.