Operator overloading, structs

[Leandro Lucarella]

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 =)

[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...

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". Most languages do that...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
De las generaciones venideras espero, nada más, que vengan.
	-- Ricardo Vaporeso