2 ms·
You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this: > Our experi
by theamk 7y ago
You are talking about section 1.8. I agree, it is not that scary. What is scary, however, are sections 2.1 and 2.2. They contain stuff like this:
> Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals.
This does not name it, but doesn't this refers to all those discussions about changing internal representation of std::string, std::vector and so on?
This does sound pretty scary. Once you have separate classes for "C++23 std::string" and "older std::string", you can no longer link together files built with different versions.. and this means you lose a lot past compatibility.
- kllrnohj 7y ago> you can no longer link together files built with different versions True but this is already something that isn't really "supported" broadly. Some standard libraries work hard to keep that working, but others tend not to, and nobody knows if it's supposed to work reliably or not. And support for this binary compatibility also varies across platforms, like I don't think Microsoft bothers since you're supposed to always bundle a specific version of the runtime with your binary. Single-version prebuilt libraries become more of a problem, but are those that widespread vs. source-based libraries? But I think the broader point here that the paper is really pushing is for the committee to actually make a statement on things like this instead of their historically vague "it sort of works but we're not saying it will or indeed saying anything at all"