Firstly, I need to apologize. My previous mail on this topic was a bit
dismissive of Blair's comments, and shouldn't have been. I was getting
defensive of those commits, and it showed. I really do appreciate the
review; it helps me learn to be a better hacker. Thanks.
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.
Thanks again for the input!
-Hyrum
Received on Fri Apr 13 03:35:06 2007