Earlier quoted context omitted.
> That's all well and good, but what would you do exaclty? Start with having the standards committee accept that they are in fact where the buck stops, and that the language includes, whether they like it or not, the toolchain. They don't have to decide upon the toolchain, but their current MO of "toolchain/ABI issue == not our problem (except for when we decide we're not willing to make any backwards incompatible AB…
> 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…
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.