On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg
<[email protected]> wrote:
Andrei Alexandrescu wrote:
Brad Roberts wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Walter Bright:
Think of it like the "bool" operator overload. bool gives a direct
way for user defined times to be tested for if statements, etc.
Similarly, U+ gives a direct way for user defined types to be
converted to their most desired arithmetic type.
I'd like opBool in D, for example to implement multiprecision numbers
that can be used as integers in: if (somenumber) {...
Unfortunately experience with C++ has shown that things look simpler
than they are. If opBool is an implicit conversion to bool, then all
sorts of weird expressions are allowed. That's why conversion to bool
is
flat out unrecommended in C++. Instead, various libraries found
alternate ways to allow testing with if without compromising things
too
much. Loki uses conversion to an opaque pointer type. Boost uses
conversion to a pointer to member. The standard itself uses, I think,
conversion of iostreams to void*.
Isn't one of the key problems that bool conversion introduces is the
follow on
conversion to integral types? If implicit bool -> integral conversion
wasn't allowed, T -> bool conversion would be less problematic, no?
That is correct, and "less problematic" is exactly how I'd put it.
There's a problem left. Assuming bool -> numeric conversion is
impossible, there's still a problem. First, consider a class, array,
pointer, or number x. This compiles:
if (x) stmt
This also compiles:
x ? expr1 : expr2
But this doesn't compile:
bool b = x;
Now consider we design tests to use opBool that effects implicit
conversion to bool. Then, for a user-defined type x, all of the three
samples above compile. Which means we have introduced a gratuitous
incompatibility between user-defined and built-in types.
Then consider another problem: a type that allows if (x) also wants to
allow if (!x). It's the natural thing to want. Then we need to define
opBool and opUnary!"!" to work in concert, redundantly. Bleh.
I'm not sure how big problems these are. I think they are threatening
enough that style manuals and coding standards mention both.
Using double negation !!x throughout, there are only advantages and no
disadvantage. I hit that design with Pacquiao punches over the past week
or so, and couldn't find any shortcoming. It's consistent across
positive and negated uses, easy to understand, easy to define,
consistent with built-in types, and Walter likes it.
Andrei
Couldn't we solv that by instead of introducing opBool, introduce opTrue.
Which is defined as yielding a type testable for truth and is only
invoked
in the same situations that class references are used as thruth values?
To
me this looks like a simple solution.
OpTrue also implies opFalse, which is redundant.
