yank unary '+'?

[Johan Granberg]

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.