Blair Zajac wrote:
>> Branko Čibej wrote:
>>> Hyrum K. Wright wrote:
>>>> Interesting. The standards committee must have included the implicit
>>>> conversion operator capabilities for /some/ reason, though. If the
>>>> only
>>>> reason *not* to use it is that there's "too much magic" going on, I'm
>>>> not sure that I completely buy that. I'm just concerned that we're
>>>> throwing the baby out with the bathwater in an attempt to make things
>>>> foolproof.
>>>>
>>> Like many interesting features of C++ (and C), implicit conversions can
>>> be indispensable in some cases, but are dangerous most of the time. If
>>> you don't need them, don't use them.
>>>
>>> In this case, the you can get the syntactic sugar by adding inline
>>> overloaded functions that accept a const Path& to wrap the API
>>> functions. The effect on the syntax is the same, but you avoid the
>>> dangers of the implicit conversion being triggered when you don't
>>> actually want it, due to an all-to-easy programming error.
>>>
>>> To turn your argument around: The standards committee included the
>>> 'explicit' keyword so that programmers can create single-argument
>>> constructors that aren't implicit conversions precisely because implicit
>>> conversions are so inconvenient in the general case.
>>
>> So, I've been thinking about this for quite a bit today. I even googled
>> around for a bit to see what the general feel was about implicit type
>> conversion. I was surprise to find that it was almost uniformly the
>> same sentiment which Blair and Brane have shared. It seems that
>> implicit type conversion is almost universally considered Evil, and to
>> be avoided; a feeling I was not aware of.
>>
>> The method mentioned above is a valid one, but also feels like overkill
>> for our use case. The functions in which we've made the changes *are*
>> the wrappers, and it would be redundant to introduce yet another
>> wrapping layer just to provide syntactic sugar.
>>
>> So, the simplest thing seems to just revert r24541, r24557 and r24558,
>> and see where we go from there. I may wait a couple of days to do that,
>> though, to see if others want to chime in on this conversation.
>
> +1.
Done in r24595.
-Hyrum
Received on Mon Apr 16 23:22:45 2007