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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk