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
