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