Re: [boost] Variadic append for std::string

Subject: Re: [boost] Variadic append for std::string
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-01-26 17:28:47

On 27/01/2017 03:04, Hans Dembinski wrote:
> You don't know why the user added the overloads for foo, perhaps she
> suddenly had to adapt foo so that it also works with C code which
> uses a lot of const char*. As a designer, you have no control over
> other peoples' interfaces.

That wouldn't be a problem, because no sane implicit conversion could 
ever return const char*.  And even if std::string had its own conversion 
(which it doesn't), the compiler won't chain two implicit conversions, 
so it can't be ambiguous.

For string vs. string_view: I don't think returning string_view is 
practical for concat/join anyway, since they don't have a pre-assembled 
string to return a view onto; the string isn't constructed until the 
actual concat call, and this can't return a view as it has nowhere to 
store the "real" string to keep that view valid.

The only other one that seems more likely is if the factories could 
output std::wstring as well as std::string, since it's reasonable that 
user code would have overloads for both (or accept basic_string).  In 
practice though I don't think even this would be a problem, as:

   std::string x = concat("foo", "bar");
   std::wstring y = concat(L"foo", L"bar");
   std::wstring z = concat("foo", bar");

x and y are well-formed; z is not.  Converting between character types 
is a potentially lossy operation (and ambiguous in the case of wstring 
to string -- did you mean to convert to UTF-8 or some other encoding?) 
and as such never makes sense as an implicit conversion.  If you want 
that, you will have to put in an explicit conversion request, either on 
the output of concat or on both of its inputs.

(Similarly concat should not accept mixed inputs as parameters either.)

So I don't see these as real concerns.