Re: Opinions on introduction of string_view in Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-18 11:47:06

On 10/18/21 4:22 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> Ok, let it be
>>
>>   template< typename T >
>>   inline typename enable_if<
>>     is_same< T, std::string_view >,
>>     std::string_view
>>   >::type api_function( T str )
>>   {
>>     ...
>>   }
> 
> And now C++17 users are sad because when they call
> the function with a literal or a std::string it returns a
> boost::string_view, which they can't assign to a std::
> string_view.

Ok, then make std::string_view the default in you API. Write down the
requirements you have and write the code accordingly, it does not look
impossible to me.

> You'd probably have them use a conversion function
> on each call. That's workable but does not exactly deliver
> the best user experience.
> 
> No, the correct answer is that you write your own private
> string_view and use that.

Writing more string_view types is not the answer for the reasons I wrote
earlier. At some point you will have a problem of interoperability
between those types, only more of them.

> (Or tell your users to switch to C++23 I suppose.)

I'm not sure what C++23 has to do with this.