yank unary '+'?

Denis Koroskin 2korden at gmail.com
Mon Dec 7 00:45:45 PST 2009


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.



More information about the Digitalmars-d mailing list