Re: Opinions on introduction of string_view in Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-18 01:21:15

On 10/18/21 4:05 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>>> Remember that libraries also need to return string_views.
>>
>> Yes. Depending on the case, this can be worked around too. For example,
>> have a convention that if you accept a string_view, you return the same kind
>> of string_view as well.
> 
> And now all code that used to pass string literals or std::strings is broken
> because of ambiguity.

Then you'd use SFINAE or template matching to resolve the ambiguity.

> And if you add overloads to fix the ambiguity
> (remember that the whole purpose of string_view is to let you get by without
> adding overloads), you can't return both string views at once.

Sorry, I didn't understand the "both string views" part.

>> If you don't accept a string_view, let the user choose
>> what he wants. Pick a default, if that's too verbose.
> 
> How would that work, exactly? Take the example function signature and
> show us how it's done.

  boost::string_view get_string();

  template< typename String >
  String get_string()
  {
    boost::string_view res = get_string();
    return String(res.data(), res.size());
  }

Look, I'm talking in abstract code here. Perhaps, I'm missing some
crucial use case that you and Vinnie are aware of that absolutely never
can work like this. Perhaps you could present such use case and we can
think how it could be improved.