Operator overloading, structs

[Don]

Leandro Lucarella wrote:
> Don, el 10 de junio a las 03:50 me escribiste:
>> Leandro Lucarella wrote:
>>> Don, el 10 de junio a las 02:02 me escribiste:
>>>> bearophile wrote:
>>>>> Leandro Lucarella:
>>>>>> I think the more general solution is to allow multiple implicit cast
>>>>>> operators and simply provide implicit conversion to bool for the classes
>>>>>> you want to be able to do if (x) on.
>>>> No, it's not more general.
>>> *it is* more general, that's exactly what you don't like about it =)
>> If you consider "also introduces bugs" as "more general"... I just call that "wrong" <g>.
> 
> No, I consider "not specialized or limited to one class of things"[1] as
> "more general". I'm not discussing if generality makes easy to introduce
> bugs in this case, that is what you are implying =)

I'm implying that it does NOTHING other than introduce bugs.
If you want to be pedantic: it does not reduce the limitations on useful 
behaviour.

> 
> [1] Meaning taken from here http://wordnetweb.princeton.edu/perl/webwn?s=general
>     (I've choose the meaning that better fit what I was trying to say)
> 
>>>> C++ libraries go to a fair bit of trouble to allow if(x) without
>>>> allowing x to be converted to bool.
>>> I don't think is a *disaster*, but I agree that maybe the distintion can
>>> be useful (I didn't though about that). 
>> It's very important. If you allow implicit conversion to bool, all kinds
>> of garbage will compile. You might as well abandon static typing.
> 
> Again, I think this is a little too drastic.
> 
>> That makes me think, why not to
>>> disable implicit cast from bool to int? It's even defined what the value
>>> of int x = true; should be?
>> Yes. It's 1.
>>
>>> I guess there are plenty of cases where you
>>> don't want that, but I can't think of anything now...
>> I can't think of any case where it's a good idea. (It's required in D1
>> because opEquals() stupidly returns int).
> 
> I don't think is *required*, you can do an explicit cast, but it wouldn't
> be very nice indeed. BTW, wasn't that finally changed? Or it was a D2 only
> change?
> 
>> But that still leaves the problem:
>>
>> bool b = x; // doesn't compile if x is a class, or an array, or an AA.
>> But it would compile if x is a struct with implicit conversion to bool.
> 
> I don't understand why that should not compile if the class/array/AA has
> an implicit conversion to bool defined.
> 
>>> Of course, int to bool implicit cast should still be possible.
>> No. It isn't legal now! Only the special case of literals 0 and 1. Which is perfect.
> 
> So is:
> 
> int x;
> // ...
> if (x)
> 	// ..
> 
> A special case? That's odd...

It's a special idiom, which you mention at the end of your post. It 
doesn't involve implicit conversion to bool. Thus avoiding bugs.

> I think it makes perfect sense to allow implicit conversion from int to
> bool. I don't think bool should be considered a "numeric type" to be
> concerned about the precision loss (or there is another reason not to
> allow that?).
> 
>> The only time when you want to allow an implicit conversion to bool is
>> when you have some kind of "smart bool" struct which is supposed to be
>> a drop-in replacement for "bool". It's quite distinct from
>> if(x) --> if(x!=0).
>>
>> The strength of my proposal is that it would allow existing code to
>> "just work" without modification. You wouldn't have to think about it.
>> To argue against it, find a situation where it would be a problem.
> 
> I think implicit conversion to bool is a very common idiom to quickly ask
> if something is not "empty".

That is not correct. if(x) does NOT involve an implicit conversion to 
bool. That's the key issue.