Closed vvish closed 3 years ago
Hi @vvish
Thanks for bringing this up.
I've trouble to trace back where the idea for non-member first()
etc. comes from. Given these functions are not available from namespace nonstd
carries the suggestion that the idea/implementation isn't 'fully baked'.
Think the implementation is chosen to reduce the number of overloads needed by letting make_span()
do most of the work. Wondering if the wide contract of first()
etc. can lead to problems.
The changes in your fork seem good to me (after a quick-ish look).
Whether it would be better & enough to have first()
etc. accept span<T>
as argument, I'd appreciate to be educated on :)
Thank you @martinmoene for the quick reply.
The documentation https://github.com/martinmoene/span-lite/blob/master/README.md#first-last-and-subspan suggests that they were introduced "to avoid having to use the dot template syntax when the span is a dependent type". It looks like if it is the only intended usage then they could receive already constructed span<T>
and simply delegate call to the member (this needs to be validated).
If they also act as 'factory' functions constructing sub-spans from span-compatible types (instead of chaining, like make_span().first()
), then they require wide contract and changes from my patch seem to be relevant.
I think in both cases, this functions should be available in nonstd
namespace.
Hi @vvish
I think merging the changes you prepared seems a good start.
Then look if first()
etc. can be made to take span<T>
as argument or if they should remain factory functions.
Hi @martinmoene , That was quick :). Thank you.
And thank you very much for your lib-s. They are of great aid.
Thank you, nice to hear :) You're welcome.
Perhaps continue with a new issue like 'Change free functions first(), last(), subspan() to take a span?' to investigate this aspect?
Hello,
I have a question regarding the design of the free functions:
subspan
,first
andlast
: As they do not explicitly acceptspan<T>
are they intended to be used with any type that can be accepted bymake_span
function? If it is the case then the implementation seems to have an issue: as ADL is not finding them with non-span-specialization parameters the call to this functions should be qualified (currently they are not available in thenonstd
namespace) andmake_span
in the trailing return type expression should be visible for non-ADL. Unfortunately the unit-tests cover only the cases where the span specialization is passed to the functions (works because of ADL), so it is not clear if the use-case was considered, although I personally find it to be useful (would be glad to contribute here).If the functions are designed to be used with span-s only as wrappers for methods to avoid
.template
then maybe they could acceptspan<T>
?Could you please clarify the use cases and rational behind the design?
Thank you.