Thanks for the downvote...? Not sure what the point of that was.
I haven't used C++ much since modules were introduced. From doing some quick reading, it seems unclear whether they significantly improve compilations times in practice. I wasn't able to find anything which addressed how they relate to the ABI... I suspect this is a pretty complex topic. If you have any good references related to either of these points, I'd be very eager to read them.
Either way, "C++ with modules" appears to me to be unlikely to clear the bar set by "C with opaque types" (which, for all intents and purposes, can be done in C++) in terms of 1) ABI stability and 2) encapsulation. I consider point (1) to be related to point (2), since details which are leaked into the ABI are not encapsulated.
Importing the whole standard library as defined by C++23 import std; is quicker than doing a plain #include <iostream>, as shared per Microsoft employees in some talk they have done regarding upcoming C++23 support.
Unfortunely I can't remeber which one it was, but someone else can glady share the link.
Second by having template details marked as private on the module metadata, that isn't directly exposed to consumers.
As for the ABI specifically, that is compiler dependent anyway.
I haven't used C++ much since modules were introduced. From doing some quick reading, it seems unclear whether they significantly improve compilations times in practice. I wasn't able to find anything which addressed how they relate to the ABI... I suspect this is a pretty complex topic. If you have any good references related to either of these points, I'd be very eager to read them.
Either way, "C++ with modules" appears to me to be unlikely to clear the bar set by "C with opaque types" (which, for all intents and purposes, can be done in C++) in terms of 1) ABI stability and 2) encapsulation. I consider point (1) to be related to point (2), since details which are leaked into the ABI are not encapsulated.