@pauldreik There might now be a slight conflict.

How about adding a template, that would be enabled if the argument has methods size() and data()? Then we may use string_view as well as span (and likely some more containers).

@WojciechMula

How about adding a template, that would be enabled if the argument has methods size() and data()?

template <typename T>
concept spannable = requires(T v) {
                        { v.size() } -> std::convertible_to<size_t>;
                        { v.data() } -> std::convertible_to<const char*>;;
                      };


template <spannable s>
void f(...) {...}

@WojciechMula

How about adding a template, that would be enabled if the argument has methods size() and data()?

template <typename T>
concept spannable = requires(T v) {
                        { v.size() } -> std::convertible_to<size_t>;
                        { v.data() } -> std::convertible_to<const char*>;;
                      };


template <spannable s>
void f(...) {...}

I think this is good - but maybe we can pull it further by checking if it is convertible to span.

@lemire and @WojciechMula : I have now implemented enough of this to get a feel for how it works. I think it would be useful with an early review.

I think that this is absolutely fantastic work. It will be fun to document it.

I sort of imagined something of the sort, but what you are doing is so much better... :-)

@pauldreik I am marking this PR as 'approved' because my objection can be handled as a separate step.

This is possibly optimistic as far as system support is concerned. Compilers do not support C++20 entirely and here we need concepts and spans.

I recommend guarding with something like this...

#if SIMDUTF_CPLUSPLUS20
#include <version>
#if __cpp_concepts >= 202002L && __cpp_lib_span >= 202002L
#define SIMDUTF_SPAN 1
#endif // __cpp_concepts >= 202002L && __cpp_lib_span >= 202002L
#endif // SIMDUTF_CPLUSPLUS20

And then everywhere, check that SIMDUTF_SPAN is defined.

sure. do you have an example of such a system?

@pauldreik I do not have a specific example in mind. That's why I wrote that you may have been optimistic. But, as a rule, I am sure you will agree that it is better to be careful... as the consequence otherwise is a broken build... which is not good.

LLVM 10 will report that it supports C++20. The Node.js runtime builds with LLVM/libc++ 12. Yet C++20 is only partially supported even today...

https://libcxx.llvm.org/Status/Cxx20.html

https://clang.llvm.org/cxx_status.html#cxx20

Thus I recommend we check feature macros. That's what the C++ standard people want us to do anyhow.

(I know you are not arguing with me, I am writing this largely for the people might read this exchange and wonder.)