dsimcha wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Yigal Chripun:
why not just use (i != 0) in both cases?
Yes, here it can be done (if Don has implemented opEquals(int y)),
but you don't
need that once you have something like opBool.
conversion of ints to bools in C is IMO a hole in the type system
due to the lack of a boolean type in C. All those narrowing
implicit casts inherited from C are a bad idea IMO.
Walter was right, converting a generic integral to bool requires
some time, that
in the middle of the the nested loop can slow down code a bit (5%, in
a case of mine).
A standard opBool method allows you to tell when a collection is
empty, like an
empty string, an empty range, an empty array, and so on. you can use
it instead of somecollection.isEmpty().
Java as Pascal keep booleans and integers separated, this looks
tidy and clean.
I love clean things, but in practice I don't think the current design
of D (and C, Python, and several other languages) leads to a
significant amount of bugs. It seems one of those situations where
practical considerations win over purity.
For D and other close to the metal languages, IMHO the int-bool
relationship should stay the way it is simply because that's the way
it works on the bare metal (at least on x86, for example,
instructions like jz). I think this is a good rule of thumb in a
close to the metal language, and even in the general case: When in
doubt, do the thing that gives the user the least obstructed view of
how things "really" work at the next lower level. This avoids lots
of silly abstraction inversions (One of which is building a strong
boolean type on top of an int).
close to the metal does not imply in any way you code with binary
op-codes or assembly concepts. all it means is that it does not force
upon you costly abstractions and mechanisms like a VM. this does not
apply to this discussion since a bool type doesn't require a VM and does
not penalize performance in any way.
your abstraction inversion example doesn't apply here. The problem I see
is the narrowing implicit cast, i.e. int values behave like booleans. I
have no problem with the reverse which is what your example is about.
