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.