I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. I would much rather gcc saw me passing a span around and could treat it as a special built in type.
>Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself.
False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.
That would be an ABI break which is just not happening, and you know it. As it is we’ve decided it’s more important to be able to use std span from libc++ on clang than it is to have an optimised version for people on their tool chain.
So you're saying that turning std::span from a standard library class into a language feature wouldn't break the ABI? How so? How would such a language construct fit into the existing ABI?
(for context: parent is referring to the fact that x64 calling conventions mandate structs larger than 64 bits to be passed in memory, which means that passing a 128bit std::span is going to be less efficient than passing a separate 64bit index and 64bit length, as those can go into registers)
No, the cat’s out of the bag with span (and unique pointer) now, we can’t go back. We knew this was a problem from unique_ptr and had an opportunity to not make the same mistake again, but instead we chose back compat for a new feature over something novel and performant
What is the issue exactly? Span is trivially copyable and destructible and, at least with the Itanium ABI, it can be passed (and returned) via registers: https://gcc.godbolt.org/z/4rbcshve4 .
Other ABIs might have different constraints but there is no reason why they couldn't special case std::span. In fact if span was a built-in type there is nothing preventing a compiler form picking a suboptimal ABI and being stuck with it. In any case it is not a standardization issue, but purely a QoI.
Yes, GCC can pass it in two registers. On the other hand Microsoft's x64 ABI doesn't:
>Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are passed as if they were integers of the same size. Structs or unions of other sizes are passed as a pointer to memory allocated by the caller.
The parent commenter handled the ABI question for me, but I want to respond to :
> In any case it is not a standardization issue, but purely a QoI.
This is an enormous problem in the C++ ecosystem - playing hot-potato with whose fault it is, instead of trying to actually fix it. Span is a decent example, the standards committee get to say it's a vendor issue, and the vendors get to say that their hands are tied by the ABI. The result is that people spend time arguing about who should fix it rather than actually fixing it.