yank unary '+'?
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Dec 6 22:29:14 PST 2009
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
More information about the Digitalmars-d
mailing list