On 27/01/2017 23:48, Hans Dembinski wrote:
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");
So let's say concat returns a factory with implicit casts to std::string and std::wstring. And I have function foo(…) which accepts std::string and std::wstring. Now if I write
foo(concat(42))
I get an ambiguity again.
concat should never provide implicit casts to both string and wstring, because that's silly. (Read further in my original message, where I mention that z above should be a compile error.) concat("foo", L"bar") should also be a compile error. If you use char-based parameters, it should only provide the conversion to string. If you use wchar_t-based parameters, it should only provide the conversion to wstring. If you don't use either, then either it needs to default to one or the other (most likely string), or you'd have to explicitly specify, eg. concat<char>. Which one of these would actually happen is likely to arise as an implementation detail, but the second seems more likely to me as part of the argument filtering.