Agreed. If ABI wasn't an issue, these things would have just been fixed and everyone told to go recompile everything. But C++ can't do that, so instead these are problems that need serious thought to handle into the future.
I don't see how this is saying that against the statement that C++ has been able to provide a stable ABI at the expense of flexibility into the future. Rust would have the same thing. See the threads on struct packing and such happening here. These would all be DOA and "please wait for Rust v2" the stock answer.
The language says nothing. Implementations make these guarantees (and have the power to effectively veto changes that would force them to break these guarantees). GCC uses its ABI where it compiles. MSVC uses its on Windows. They're different. Clang and Intel (EDG) both play in both realms and support both.
Templates can be instantiated in shared libraries and exported (with no template method impls exposed) just fine. Because the compiler guarantees an ABI, it can just generate the symbol references and let the linker sort things out later.
I agree. I would say that most of C++'s issues come from mixing these 2 use cases.
For (1) one could tolerate periodic ABI breaks. Maybe not every single release like in Rust right now, but sometimes. Linux distributions would have to settle on one compiler release to use for the distro, like they do now. Maybe the Rust compiler could put the metadata-reader into some sort of plugin, so that crates compiled with older rustc releases could still be read and used, by using the old reader plugin with the new compiler.
For (2) given the right tooling the brick wall might not be non-exstistant, but possibly be not too high. For Plugin-systems or System Libraries, I would consider it okay that you have to define the API Interface a bit more thoughtfully. Also, I do consider better FFI support to be important here.
Not just how, but also what is stored in the crate metadata changes between releases, so it is fundamentally impossible for one rustc version to read metadata from another version, even if a shim is written for the exact format. For example lang items and intrinsics get changed all the time. You need a standard library matching the rustc version for the right lang items to be provided and intrinsics to be used. The only thing that would be possible is to let one standard library for each compiler version to be used, but that will result in symbol conflicts if symbols from the standard library are exported as they do with --crate-type dylib. This is not a problem for --crate-type cdylib, but then no crate metadata is emitted.
Windows have COM and it is the right kind of tool. They've built the new system API on it (the WinRT) and made it easily consumable with different languages, which I think was a very good idea.
Unix world would really needs something similar. GObjectIntrospection might be such thing, or it might be such a thing, or it might be a good foundation (I would like to see support for fat pointers to avoid wrapping everything when providing interfaces).
All of that can be handled by tooling external to the compiler, just like COM or GObjectIntrospection are for C and C++ (Microsoft created a C++ extension for COM, C++/CX, but then scratched it again and replaced it with a bunch of templates and some code generation).
It can start as 3rd party tooling for sure, but in the long term there needs to be “official” tooling, because everybody needs to be using the same system to get the compatibility that we want from it.
The subset of the language should allow much more than a plain C ABI though. It should allow instances implementing traits and it should define resource management so Boxes and Arcs can be passed.