Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-26 10:08:03

On Mon, Nov 26, 2012 at 6:13 AM, Andrey Semashev
<andrey.semashev_at_[hidden]>wrote:

> On Mon, Nov 26, 2012 at 5:48 PM, Daniel James <dnljms_at_[hidden]> wrote:
> > On 26 November 2012 13:26, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
> >> On Mon, Nov 26, 2012 at 4:52 PM, Daniel James <dnljms_at_[hidden]> wrote:
> >>> On 26 November 2012 11:56, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
> >>>> The problem with std::string is the same as with string_ref - it
> >>>> doesn't support implicit construction from an arbitrary range, so my
> >>>> examples with custom string types would still not work.
> >>>
> >>> Shouldn't construction from an arbitrary range be explicit? Arbitrary
> >>> implicit conversions are problematic. To get implicit construction
> >>> from third party strings, I'd use some sort of explicit customisation
> >>> mechanism.
> >>
> >> If the string_ref or range type (let's call it contiguous_range< const
> >> char* >)
> >
> > A string isn't the same thing as a range of characters.
>
> Why?
>
> >> is not implicitly convertible from other string types then it
> >> is useless for use cases I pointed out. The thing is to make
> >> interfaces transparently support any string types.
> >
> > That's why I suggested a customisation mechanism. Something would
> > allow you to indicate that a third party type is a string and, if
> > necessary, how to get a string_ref from it. Perhaps an ADL hook, or a
> > template class that is specialized for strings, or something else
> > entirely.
>
> That would mean that the range is limited to strings only. I'm not
> sure this limitation is justified.
>

I agree with Andrey. At least for what Marshall was originally proposing
this for, iterator_range< char [const] * > seems sufficient for the API of
string algorithms. I don't even think a contiguous_range template need be
defined (as I had suggested earlier and as Andrey had also mentioned); just
partially specialize iterator_range< T * > if you want a broader API than
what iterator_range already offers. E.g., add implicit conversions from
other contiguous ranges of Ts (this assumes some hook to determine whether
a range is a contiguous range; I like the previous suggestion to add a new
traversal category deriving from random access).

- Jeff