kristina added a comment. My misunderstanding then, I was eventually hoping for a feature freeze of ABIv2 to a point where it's considered stable so any alterations to things like internal layout of std::string (ie. like SBO that came with ABIv2) happen in `unstable/std::__3` as this allows for major ABI breaking changes to slowly start integrating into various other downstream projects. If it remains unstable then there is more hesitation when it comes to vendors switching ABIs; perhaps in a major OS release, while still providing ABIv1 libraries for compatibility. I'm not really involved in libc++ evolution but it seems logical that adoption of ABIv2 should begin somewhere (even if Fuchisa remains on unstable for the time being) since it does bring notable benefits.
In https://reviews.llvm.org/D52660#1249761, @ldionne wrote: > I don't think we've ever had plans to freeze the ABI v2 into something stable > -- this is the first time I hear about it. I'm not saying it does not make > sense, by the way, just that I haven't heard any plans about this. Does > Fuchsia have a desire to stabilize the ABI of libc++? Well as I said, I have no say in how C++ language or standards or libc++(abi) evolve, but it seems to be the next logical step (though perhaps it could wait until Clang 8 and C++20 since that may require breaking changes which make sense to do within ABIv2 while it's still unstable). Otherwise aside from unreleased operating systems, having it formalized may encourage downstream vendors, especially Linux based ones, where fragmentation is normal to slowly begin adopting it. Anyway, sorry for straying offtopic, patch itself LG. Repository: rC Clang https://reviews.llvm.org/D52660 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
