> except for when we decide we're not willing to make any backwards incompatible ABI changes
That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries.
> Except there is. If I write an implementation of the standard library, and provide an implementation of std span
if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example).
> But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.
[Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64]
But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance).
(Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).
> The committee is not willing because the implementors explicitly said it is not going to happen,
Yeah, and I think this is the problem at the root of my gripe. If the committee was willing to reach this point earlier I think we’d be better off!
> But implementors are not: they can bless their own span with superpowers if they want to
Except that they don’t. And we can go around in circles here - I maintain this is a design issue, and it should be fixed at the design stage, rather than passed on to the compiler vendor who are stuck behind the theoretical design that pretends an ABI doesn’t exist, and their customers who will not upgrade if they break the ABI.
Lastly, I agree that the committee cannot force conformance or optimality, nor should they. But their unwillingness to accept that unless it’s technically impossible, the vendors will move mountains for conformance. This leaves us fighting with each other over who is to blame (see this thread), and in my opinion the end result is a half baked outcome that solves the paper problem but doesn’t solve the actual users wants.
>> But implementors are not: they can bless their own span with superpowers if they want to
> Except that they don’t. And we can go around in circles here
Except they do. Look at GCC code for std::complex compared to the equivalent hand rolled class:
https://gcc.godbolt.org/z/nqcvhPWex .
edit: note that in this case GCC is just silly with the hand rolled one, but it does show that they are treated differently.
GCC does similar things with span where the class has special annotations for reference tracking to improve warning messages.
Library vs builtin is an implementation issue, not a standardization one. But yes, we are going in circle.
That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries.
> Except there is. If I write an implementation of the standard library, and provide an implementation of std span
if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example).
> But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.
[Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64]
But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance).
(Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).