yank unary '+'?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-12-07 23:52:04 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Michel Fortin wrote:
>>> On 2009-12-07 01:29:14 -0500, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> said:
>>>
>>>> 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.
>>>
>>> I'm not sure that's a great idea. What if you define your own 
>>> FuzzyBool type (containing some sort of probability) and 
>>> FuzzyBool.opUnary!("!") returns an inverted FuzzyBool (with 1 - 
>>> original probability) instead of a regular bool, you'd have an 
>>> infinite loop trying to evaluate !!myBoolValue.
>>
>> Yeah, I thought about that liability and decided to discount it as a 
>> design mistake of the user. If a type decides to return non-bool from 
>> "!", they are bound to unpleasantly surprise its user in more ways 
>> than one. You can define a negate for FuzzyBool - just don't dress it 
>> as the "!" operator.
> 
> To me, its using "!" to transform something to a bool that looks like a 
> hack. Surely there's a more explicit and intuitive way to define it that 
> doesn't tie it to a specific operator.

Actually this is quite what happens with built-in types. A common 
misconception (I'm sure not yours) is that "if" works with Booleans. In 
fact it works with Booleans, numbers, pointers, arrays, and class 
references. In a very palpable way "if" is special-cased for each of these.

Then, the common misconception goes, all of those have a sort of 
conversion to Boolean that "if" taps into. Not quite, because if you try 
to assign a bool from an array or even an integer, it won't work.

What does work is operator "!". Operator "!" accept _all_ of Booleans, 
numbers, pointers, arrays, and class references - i.e., exactly the set 
of "if"-testable entities. And it uniformly yields bool. So it is an 
excellent device for hooking user-defined types into "if". I'd say it is 
not a hack at all, although it may look so at first sight. It really 
holds water.

> opTest perhaps?

opTest was on the bench for a short while, but Walter threw his hands. 
"How many operators are you going to define?" And he's right - I'd do 
with fewer rather than more redundant operators. We (will) have a method 
for defining unary operators. I don't see why make an exception of "!", 
or, worse, allow both operator "!" and opTest.

> And if you think "!" should always return a bool, then it should just 
> not be overridable and should be defined as returning the negation of 
> opTest (or whatever the name). I don't feel restricting unary "!" to 
> return a bool is sound when all other unary ops can be defined to return 
> anything.

It's possible to require opTest and then say that "!a" is always 
rewritten into !a.opTest. But then consider this fragment:

"For all unary operators except "!", the expression

<op> a

is rewritten as

a.opUnary!"<op>"()

However,

!a

is rewritten as

!a.opTest()"

Would you like to see something like that in TDPL?


Andrei