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

Subject: Re: [boost] Variadic append for std::string
From: Christof Donat (cd_at_[hidden])
Date: 2017-01-26 17:17:31

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_cast<std::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