> 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?

> 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.

I think there's some confusion here, as the various aspects of what I'm proposing have gotten split out over several posts now.

The two core things are:
- The type does not need to increase in size, as the flag is stored in the upper unused bit of the length field.
- It can be implemented without breaking ABI, with a dummy implementation that always returns false / always does a copy. In this case there's no need to store an extra flag at all so the binary representation stays exactly the same.

The dummy implementation means that whenever the library developers decide to break ABI, they can replace it with a real one. My reading up on ABI changes from the compiler vendors was not intended to dismiss the issue of ABI breaks in general, but to get a sense of how often they do them. If they break ABI only every 10 years then it would be a long time before this became useful. It seems to me that the current policies would allow a lot of people to get access to the full implementation quite soon, while not forcing an ABI break on anyone who wasn't already accepting one anyway.

The choice of when to switch to the full implementation ultimately rests in the hands of the library developers, and nothing is forced on anyone. In the meantime, everything is set up so that the api is ready for the future.

26 Dec 2020 6:38:36 am Tony V E via Std-Proposals <std-proposals_at_[hidden]>:

> An implementation can probably hide the ‎bool inside an unused bit of the pointer (or length), so it can still be 16 bytes.
>
> But you still have ABI problems. You could not pass a new string_view with the bit set into old code that was expecting a valid pointer, unless the old code was for some strange reason already masking out unused bits. Which is highly unlikely, to say the least.
>
>
> Sent from my BlackBerry portable Babbage Device
> Original Message
> From: Jason McKesson via Std-Proposals
> Sent: Friday, December 25, 2020 11:33 PM
> To: std-proposals_at_[hidden]
> Reply To: std-proposals_at_[hidden]
> Cc: Jason McKesson
> Subject: Re: [std-proposals] Avoid copies when using string_view with APIs expecting null terminated strings
>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals