On Fri, Dec 25, 2020 at 8:26 PM Tom Mason via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On further reading of the GCC docs (yes, on christmas day, but everyone else has gone to bed already :p), it seems libstdc++ does have a mechanism similar to that of libc++. The -fabi-version flag (docs here https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html) can be used to specify an abi version, and modern versions of gcc defaults to 0 (latest). So, the new ABI version could implement the termination flag, and the old ones could just default to not terminated. I'm sure there are gcc contributers on here, so sorry if this was all obvious, I just thought it was worth mentioning for clarity.
> I will probably do up a new, more proper writeup and example implementation in the next few days. As I'm new here, can anyone with experience comment on the likelihood of acceptance of this proposal? From my (optimistic) viewpoint, the main blocker would be ABI issues, as opposed to objections to the feature itself, and I think the workarounds are acceptable.

You can't wallpaper over an ABI break with "well, there's a compiler
switch, so it's fine to break ABIs." What happens if you want to link
against a DLL compiled with a different switch? Do you have to have
two separate compilations of *every* library, just in case someone
wants to link against the other ABI?

It took a long time for libstdc++ to upgrade its `std::string` type to
be C++11-compliant (ie: removing all the copy-on-write stuff). And
that was a change that likely improved performance across the board
for most applications. ABI breaks are not something one should do
lightly; they should only be done when the gain is greater than the
cost. And I don't feel your proposal is *nearly* good enough to
justify that cost compared to any of the non-ABI-breaking
alternatives.

And you shouldn't ignore issues besides the ABI break. From a purely
practical perspective, you're talking about turning a type that's 16
bytes in size (64-bit compilation) into one that must be 24 bytes in
size. That's a fifty percent increase in the size of the type. That's
a cost *everyone* must pay, even those who don't need the feature. You
can only justify such a cost increase by having this solve a
*pervasive* problem. And I don't think the issues you've cited
constitute that.

Remember: the use case you're talking about is an API which both
internally needs a NUL-terminated string and also does not want to
*force* the user to provide a NUL-terminated string view. That is, the
API is perfectly happy to do the copy; you'd just prefer not to if
that's OK. I don't believe this is particularly common. Certainly not
common enough to be worth making every string view 50% bigger.