On Monday, 19 September 2022 20:07:28 PDT William Linkmeyer wrote:
> > How is that different from what we have today?
>
> In some cases, a standard’s symbols might not change, but the binary layout
> will in consequential ways.
>
> For example, if I hash a value from library A, send it to a map in library
> B, and try to look it up in library B (by its hash) from a value in library
> A, I’m assuming that: 1. Symbols exist for the hashing function and the map
> object
> 2. The hashing algorithm produces the same output when the symbol exists
>
> 1 and 2 might not always be true.

You haven't answered my question.

We already have a solution for this, which is to create a new type. Inline
namespaces have their flaws and their uses, and can be used to seamlessly
switch to a new version.

So why do we need another syntax? What's the advantage of it over existing
solutions?

You need to give likely examples. Given that the standard has not required an
ABI change in over 10 years, and aside from the basic_string one which was
deemed to have been a misunderstanding of C++98, hasn't needed an ABI break
for 18 years, you'll probably have to give examples that are outside of the
Standard Library. Look at existing libraries that want to keep ABI and have to
bend over backwards to keep compatibility in things, or at libraries that
don't keep ABI but would if a few problems were solved.

I expect that you've put the cart ahead of the horses, by designing a
solution without first looking at the problems and existing workarounds.

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