On 13/07/2024 16:57, zxuiji via Std-Proposals wrote:
> I've gotten tired of this back and forth. I'm gonna put it like this,
> think of ABIs like text.
> When the only software it talks to is compiled by the same developer the
> dev can use
> whatever bloody encoding they like, other software be damned. But as
> soon as talking
> other software becomes necessary (such as a GUI library) the only real
> option is unicode.
> If you try any other encoding you'll be lucky if it's understood you
> correctly.
>
> Likewise with ABIs. When the only software the ABI talks to is software
> the dev compiled
> then the dev can use whatever optimisations on that ABI they want. The
> moment they
> need to talk to other software (say the OS itself) there are no ifs,
> buts or whats about it,
> they MUST use the ABI the OS has provided. std::stable as I see it just
> takes this concept
> to communicating between different software in general, not just the OS.

Exactly. Thanks for putting it so well.

> On a different note I'd say std::stable is a bit too verbose, perhaps
> shorten it to stdabi? Then
> just mandate that stdabi cannot be vendor defined at the ABI level, only
> at the implementation
> level and even then, only if it does not effect the expected behaviour
> of stdabi. I expect over
> time stdabi:: would become it's own thing and vendors would still have
> the option of std:: for
> their own experiments.

I'm not a huge fan of deep namespace hierarchies myself, but followed
the example set by std::ranges and std::chrono. Putting explicitly
stable classes in their own namespace reinforces the idea that other
classes are not stable, and allows them to use the same name as their
unstable counterpart, which helps with understanding.


Hans Guijt