Interesting. Thank you.

WL

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