Hi, Am 26.01.2017 15:04, schrieb Hans Dembinski:
Am 26.01.2017 10:47, schrieb Richard Hodges:
I don't see any particular reason why you can't provide all of them, though (even the implicit conversion), as different things are going to feel more natural to different people, particularly in different contexts. There's a problem with implicit conversion. imagine the overloads function: void foo(std::string const& s); [...] foo(join(...)); [...] void foo(std::string_view s); void foo(const char* s); Now the above code will not compile, because there are 3 ambiguous overloads.
But that is only an issue for users, who have relied on the implicit conversion upfront. You can always use an implicit conversion explicitly as well, of course, and implicit conversion will be just one of multiple options, if we add it.
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.
But only people, that have relied on implicit conversion, might have an issue. Richard proposed to have member functions like .str(), free functions like to_string() and implicit conversion. Use the explicit member function, or free function, and you'll be fine. Whoever, for whichever reason, decides to rely on implicit conversion, will probably get easier to read code, but . Generally, please calm down. I am not attacking you personally. I am just discussing, weather implicit conversion might be a good idea as an additional way to execute string factories. My current opinion is, that it is not my preferred interface, but as an additional option, why not? Only those, who use it, pay for it.
Why do you think the standards committee added explicit operator <type>() to the language? They don't do these language changes for fun.
They also added the possibility to create implicit type conversions. If implicit conversions really are so bad, as you put them, why did they do that? For fun? Were they drunk? And I really dislike explicit type conversions. Every time I had considered to write an explicit type conversion, a member function, or a free function with a speaking name was the better choice. So if we come to the conclusion, that the implicit conversions harms anyone, but those who use them, I'd vote for no conversion operators at all. Use the explicit member functions then.
Also, if you won't take it from us, please go and take the wisdom from Herb Sutter
http://www.gotw.ca/gotw/019.htm
"It's almost always a good idea to avoid writing automatic conversions, either as conversion operators or as single-argument non-explicit constructors."
It is almost always a good idea to listen to the wise people and then think for yourself, if what they say really fits to your situation. [Christof Donat, just now]
The call is then auto s = static_caststd::string(concat(…));
That is the worst we had up to now. Even an implicit conversion is better, which is not at all my favourite as well.
As Olaf pointed out, it is sufficient to do
auto s = std::string(concat(…));
you don't need the static_cast. Nevertheless, casts are the official way of doing type conversions, whether you like the syntax or not. I think Stroustrup intentionally made them ugly, because he wanted type conversions to be the exception in his statically typed language.
I totally agree with him. Explicit type conversions are ugly as hell, and it is good, that way. Implicit type conversions might be dangerous, so we should think twice, before we add them. But if in this case they don't hurt anyone, then I think there is no good reason to not add them. Christof