yank unary '+'?

[Johan Granberg]

Denis Koroskin wrote:

> On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg
> <lijat.meREM at ovegmail.com> 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.

It was the semantics I was after I just choose a different name to keep the
concepts appart.