If you want to use this kind of syntax, you can still make an overload that takes an initializer_list and calls the span overload by explicitly converting to a span.
Could the asm difference between using the array and the initializer list in the -O0 build be because it's grabbing the size out of the initializer list object when for the array it doesn't need to?
You can already convert explicitly from initializer_list to span, but being able to do it implicitly will be really nice. Though, isn't there also a thing now about the backing array of an initializer_list living in static storage, just like string literals? So by that logic, an appealing workaround in today's language seems to be to put the array in a static (constexpr) variable.
It would be nice if in your videos like this you explained if updates like this are or required core language changes or if they are expansions to the STL.
Unnecessary pedantry, in my opinion. Sure, a non-hosted implementation doesn't need to provide a library of any kind, but truthfully, the STL is more compile time with some generated code that you can modify yourself and also easily download a copy anyway that truthfully it should be included. In fact, it'd be nice if there weren't two array-like types and instead we could just specify const when sizing it to get the behavior of std::array, but that's a whole other argument.
@@anon_y_mousse As someone who works on libraries... it isn't pedantry. It would make it more clear how the feature is implemented and what might be possible in older releases.
@@trapexit Alright, I'll give you some leeway here since a core language change could change how the library is implemented. I figured you were one of those purists that didn't want to count the STL because it's not part of a non-hosted environment.
This is concerning, won't this break old code that uses CTAD like std::span{someContainer} ? Will there be ambiguity now as to what the deduced type of the span should be?
What do you expect, it's `clang`. I'd wager that `gcc` behaves the way that you and I would expect a compiler to behave there. Of course, `gcc` always takes a little longer to modify doesn't it. One of the drawbacks to their methodology.
The fact that this took 6 years (span came in C++20) to be implemented is the type of things that make me wish C++ evolved faster.
std::span is absolutely awesome, and amazing a interfacing with old C libraries that use C style heap arrays
If you want to use this kind of syntax, you can still make an overload that takes an initializer_list and calls the span overload by explicitly converting to a span.
Or you just stick that std::array before, it's not that much code come on...
Could the asm difference between using the array and the initializer list in the -O0 build be because it's grabbing the size out of the initializer list object when for the array it doesn't need to?
Finally!! I won't have to pass std::initializer_list in all my function call chains anymore :D
You can already convert explicitly from initializer_list to span, but being able to do it implicitly will be really nice. Though, isn't there also a thing now about the backing array of an initializer_list living in static storage, just like string literals? So by that logic, an appealing workaround in today's language seems to be to put the array in a static (constexpr) variable.
It would be nice if in your videos like this you explained if updates like this are or required core language changes or if they are expansions to the STL.
Unnecessary pedantry, in my opinion. Sure, a non-hosted implementation doesn't need to provide a library of any kind, but truthfully, the STL is more compile time with some generated code that you can modify yourself and also easily download a copy anyway that truthfully it should be included. In fact, it'd be nice if there weren't two array-like types and instead we could just specify const when sizing it to get the behavior of std::array, but that's a whole other argument.
@@anon_y_mousse As someone who works on libraries... it isn't pedantry. It would make it more clear how the feature is implemented and what might be possible in older releases.
@@trapexit Alright, I'll give you some leeway here since a core language change could change how the library is implemented. I figured you were one of those purists that didn't want to count the STL because it's not part of a non-hosted environment.
This is concerning, won't this break old code that uses CTAD like std::span{someContainer} ? Will there be ambiguity now as to what the deduced type of the span should be?
I thought this already worked :).
kind of depressed that the comiler uses static storage and doesn't use immediate values whereever it's possible.
Well in this particular example compiler doesn't know what use_data function is going to do so I don't see what else it could do.
What do you expect, it's `clang`. I'd wager that `gcc` behaves the way that you and I would expect a compiler to behave there. Of course, `gcc` always takes a little longer to modify doesn't it. One of the drawbacks to their methodology.