On Mon, Sep 19, 2022 at 10:41 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Monday, 19 September 2022 19:22:05 PDT William Linkmeyer via Std-Proposals
> wrote:
> > For example, how the `std::string` fiasco could have been avoided if the
> > standard’s compatibility range, supplied by the author, was embedded within
> > the binary.
>
> It was embedded in the binary in another way and was selectable by the user.
> It still is. See:
> https://abi.godbolt.org/z/ref4xs9M7
>
> It's just non-standard because it only affected one implementation.
>
> The fiasco happened because there was an implicit change to what "std::string"
> meant, because of the use of an inline namespace:
>
> If every type and class is always referred to by their full name, then no
> problem exists.

I'm not sure if you're referring to the same "fiasco" as William. He
appears to be referring to the change from copy-on-write in libstdc++
to small-string-optimization. This had nothing to do with inline
namespaces. I mean sure, they probably used an inline namespace for
versioning, but that wasn't the *cause* of the problem; it was just a
tool used in the building of the type.

And the full name of the (template) type is `std::basic_string`. As
far as the C++ standard is concerned, there is no other name for it
outside of the aliases that it defines.

> And if you remove the ability to change the ABI or behaviour
> in a class, then the only way to achieve a similar objective is to duplicate
> the type in question change there, making everything opt-in.
>
> In that light,
>
> using std = std::v<2017, 2023>;
>
> Is fine. Remembering, of course, that that library headers must never add
> "using namespace" or make namespace aliases in their headers. That would mean
> everyone must write the full name... which is SOURCE incompatible compared to
> today, where you can write std::something.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals