Michel Fortin wrote:
> On 2009-12-07 23:52:04 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
> 
>> Michel Fortin wrote:
>>> On 2009-12-07 01:29:14 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@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

"Brad Roberts" <braddr@puremagic.com> wrote in message news:mailman.574.1260244655.20261.digitalmars-d@puremagic.com...
> Walter Bright wrote:
>> Simen kjaeraas wrote:
>>> Leave it in. WIth unary -, we should also have its archnemesis, the unary +.
>>
>> Can't have Superman without Lex Luthor!
>
> Well, you can, but the stories would be a good bit less interesting.

Issue #473:
Superman clips his toenails!!
Hair-raising, nail-biting action!

Andrei Alexandrescu wrote:

>> "I can't imagine a use for it and removing it makes the language simpler."
> 
> I disagree

(...)

> I was mostly talking about overloading operator +. Operator + has a long history of being available for overloading in C++, which we can use to our advantage. It has been used to emulate DSLs, but I think we have much better means to define DSLs in D than to redefine all operators to mean some convention-chosen things.

Ok, so it's: "I can imagine only one use for it -- but I think we have a better way to do that -- and removing it will make the language simpler."

How is that a better reason?

I'll ask you again, because I'm really curious. Why would you remove unary plus?

* I can't imagine it would make the compiler simpler to any significant degree. If the compiler is well written, unary plus will simply occupy a standard spot in a couple of lists (parser, op-function-names, ...). I doubt removing it would even make a dent in the complexity of the code.

* Assuming for the moment that the D language and the D compiler are different things (which they aren't), would it make the language simpler? It would probably only confuse programmers who expect the natural counterpart to unary minus to be present. As for documentation, again, it's a matter of a single spot in a list somewhere.

* It doesn't, as far as I can see, take up syntax-space that might be occupied by another more useful feature.

* There are even known use-cases. Though for a simple, expected, symmetric feature such as this one, that wouldn't even be a requirement for me.

(Note that I'm not especially interested in the unary plus operator per se. I'm just using it as a convenient case-study. I'm more curious about your opinion on why language features should be adopted/tossed/kept.)

Best regards,

-- 
Michiel Helvensteijn

Bill Baxter wrote:
> I say you should completely chop it then.  Leaving it in for literals
> only leaves a mess that's hard to justify.
> I have often written things like
> 
>   glVertex2f(-boxRadius,-boxRadius);
>   glVertex2f(+boxRadius,-boxRadius);
>   glVertex2f(+boxRadius,+boxRadius);
>   glVertex2f(-boxRadius,+boxRadius);

I'm doing the same thing myself, too.

I'm using the unary plus not only for documentation, but also for expressing intention: It symbolizes that I did not forget a minus sign for that specific value. This way a missing unary minus or unary plus makes me suspicious that I have done something wrong in my numerical code.

On Tue, Dec 8, 2009 at 2:28 PM, Lukas Pinkowski <Lukas.Pinkowski@web.de> wrote:
> Bill Baxter wrote:
>> I say you should completely chop it then.  Leaving it in for literals
>> only leaves a mess that's hard to justify.
>> I have often written things like
>>
>>   glVertex2f(-boxRadius,-boxRadius);
>>   glVertex2f(+boxRadius,-boxRadius);
>>   glVertex2f(+boxRadius,+boxRadius);
>>   glVertex2f(-boxRadius,+boxRadius);
>
> I'm doing the same thing myself, too.
>
> I'm using the unary plus not only for documentation, but also for expressing intention: It symbolizes that I did not forget a minus sign for that specific value. This way a missing unary minus or unary plus makes me suspicious that I have done something wrong in my numerical code.

Well, you can use a leading space for that purpose too, with just slightly more ambiguity of intent.

--bb