On Saturday, 26 December 2020 08:36:00 -03 Tom Mason via Std-Proposals wrote:
> 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.

That's a QoI question. If you leave it to QoI, then there's nothing stopping
implementations from doing that already and providing an extension to support
obtaining the null-terminated string from string_view.

And TNSTAAFL. You have to justify the strong reason why this should be done in
string_view, which has very strict performance guarantees today. See my reply
to Tony.

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

That removes the interest in the feature. If it never works, no one is going
to use it and will either work around it or implement it themselves.

No, either it works in a good number of mainstream compilers or the feature is
DOA.

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

There's a document that libstdc++ maintainers have been keeping for 15 years
for things they might want to do if they could break ABI. There has yet to be
a reason strong enough to do it.

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

16 and a half years and counting. The last official break was GCC 3.4, in
April 2004.

Strictly speaking, the std::__cxx11::basic_string change *was* an ABI break.
They could've just bumped the soname then, but they decided to introduce a new
compiler feature to paper over the problem. Fortunately, it was very limited
and thus did not affect any ABI that didn't use std::string in the first place
(like all of Qt).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering