Hyrum K. Wright wrote:
> 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
>> 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!
Thanks for being open!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 13 19:11:01 2007