
On Mon, Nov 26, 2012 at 6:13 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Mon, Nov 26, 2012 at 5:48 PM, Daniel James <dnljms@gmail.com> wrote:
On 26 November 2012 13:26, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Mon, Nov 26, 2012 at 4:52 PM, Daniel James <dnljms@gmail.com> wrote:
On 26 November 2012 11:56, Andrey Semashev <andrey.semashev@gmail.com> 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