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.
