Customizing std::span

[Stewart, Robert]

Currently, std::span has a very specific set of converting constructors. If one has a UDT that doesn't conform to the requirements of those constructors, then one must use the pointer + length constructor, possibly by creating some custom make_span() or similar function. I propose the following converting constructor instead:

template <class T>
span(T & _value)
: span(span_traits<T>::data(_value), span_traits<T>::size(_value))
{
}

The default for span_traits can be:

template <class T>
struct span_traits
{
static T *
data(T & _value) { return _value.data(); }

static ptrdiff_t
size(T & _value) { return _value.size(); }
};

That default will work with Standard Library containers and other types that follow that pattern.

Then, if users are permitted to specialize span_traits, other types can be adapted readily, and some of the current constructor overloads could be replaced with specializations of span_traits.

There might be reason to split span_traits into two function templates, but that's a minor detail relative to the idea of adding a customization point to adapt it to other UDTs.

_____
Rob Stewart robert....@sig.com
Senior Software Engineer, Middleware using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com



________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

[Nevin Liber]

On Thu, May 17, 2018 at 1:38 PM Stewart, Robert <Robert....@sig.com> wrote:

Currently, std::span has a very specific set of converting constructors.  If one has a UDT that doesn't conform to the requirements of those constructors, then one must use the pointer + length constructor, possibly by creating some custom make_span() or similar function. 

Can't you add an operator span() to your type, similar to operator string_view() inside string?

You have to be an expert to know what you can and can't do in namespace std and in a specialization of a standard type.  We should not be encouraging this when there are better ways to accomplish the same thing.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[rste...@boost.org]

On Thursday, May 17, 2018 at 2:48:27 PM UTC-4, Nevin ":-)" Liber wrote:

On Thu, May 17, 2018 at 1:38 PM Stewart, Robert <Robert....@sig.com> wrote:

Currently, std::span has a very specific set of converting constructors.  If one has a UDT that doesn't conform to the requirements of those constructors, then one must use the pointer + length constructor, possibly by creating some custom make_span() or similar function. 

Can't you add an operator span() to your type, similar to operator string_view() inside string?

That's an intrusive change to add compatibility with an extrinsic type. What if you can't change the type? The trait approach permits adapting any type.

 

You have to be an expert to know what you can and can't do in namespace std and in a specialization of a standard type.  We should not be encouraging this when there are better ways to accomplish the same thing.

I don't see how knowing what is and isn't permitted in namespace std requires one to be an expert. It can be published on blogs, on SO, in books, etc. that one can customize std::span_traits, making it accessible to anyone. At any rate, intrusive changes are not always possible, so that's not a "better way to accomplish the same thing."

__

Rob Stewart

[Nevin Liber]

On Fri, May 18, 2018 at 6:35 PM <rste...@boost.org> wrote:

That's an intrusive change to add compatibility with an extrinsic type. What if you can't change the type?

Presumably, if you cannot change the type, you cannot change the header where the type is declared.  So now you have to put this specialization in another header, and hope that everyone includes that header instead of the original one, or you get ODR violations.  That make it expert-only and error-prone.

And if you can somehow guarantee they use the new header, then you can write your own make_span function in it w/o requiring anything from the standard.

 

The trait approach permits adapting any type.

Get GSL to add it to their span (which has been around for what, three years, w/o anyone wanting this), then gather stats on whether this is worth doing or not.  W/o evidence, this seems like a solution in search of a problem.

Or you can try and resurrect the more general solution: concept maps.

 -- 

[rste...@boost.org]

On Saturday, May 19, 2018 at 8:05:42 PM UTC-4, Nevin ":-)" Liber wrote:

On Fri, May 18, 2018 at 6:35 PM <rste...@boost.org> wrote:

That's an intrusive change to add compatibility with an extrinsic type. What if you can't change the type?

Presumably, if you cannot change the type, you cannot change the header where the type is declared.  So now you have to put this specialization in another header, and hope that everyone includes that header instead of the original one, or you get ODR violations.  That make it expert-only and error-prone.

Using a separate header was what I was thinking, but you're right about the potential for ODR violations since the header may not always be included when using span with that type. Nevertheless, adding conversion operators can get ugly quickly as the number of such conversions grows and because of the need to retrofit existing classes each time there's some new type like string_view or span, or the omission of one is detected. (There may be no better solution, but that doesn't mean I have to like it.)

 

And if you can somehow guarantee they use the new header, then you can write your own make_span function in it w/o requiring anything from the standard.

 

The trait approach permits adapting any type.

Get GSL to add it to their span (which has been around for what, three years, w/o anyone wanting this), then gather stats on whether this is worth doing or not.  W/o evidence, this seems like a solution in search of a problem.

 

This was prompted by some use cases we had when looking to create and use our own version of span. We weren't suggesting this for grins. However, it's possible that there are not very many such cases or that they are addressed sufficiently via an explicit conversion operator. We'll play with things more and see where it gets us.

Or you can try and resurrect the more general solution: concept maps.

That's a non-starter for our environment.

__

Rob Stewart