Specification of ! and + unary operators is unclear

[DartBot]

This issue was originally filed by [email protected]

---

These two operators are allowed to be used in a unary expression, but they are not allowed to be user defined. I could not find a definition in the spec for how they are supposed to behave. Here are the rough rules that I am assuming until I hear something more definitive:

1. The + operator is roughly the same as 'assert(x is num)' where it will check that it is being applied to a number type and will otherwise be a noop. My inclination would be to be even stricter here and remove this operator from the language - but add it to the syntax for NUMERIC literals as this is the place that many programmers are used to using it.
2. The ! operator will check that its argument is a bool and if so will return the opposite bool value. Otherwise it will signal an error in some appropriate way? It's a little troubling to me that I can't figure out the right error message here. MethodMissing seems correct - but there's no defined method to me missing...

Thanks for any help clarifying the behavior of these operators.

[floitschG]

I would expect !x to behave exactly like: (x? false: true)
(No need to search for error-messages).

---

Added Area-Language, Triaged labels.

[gbracha]

The spec should give definitions for operators that are not user defined, and it doesn't. User defined operators are spec'ed by the library code that defines them.

PS: mail me about high priority questions; I may overlook bugs for a day or two.

---

Set owner to @gbracha.
Added Accepted label.

[gbracha]

 I've now spec'ed both, but will move to eliminate unary + altogether. I don't know what we have unary + for. It is a no-op (for all types) and serves no purpose. FWIW, in JS, +"abc" evaluates to NaN!

---

Added Done label.

[DartBot]

This comment was originally written by [email protected]

---

Thanks for clarifying! Are you sure that you don't want us to implement + (non-number) -> NaN? It seems like such a valuable feature that I don't know why we would leave it out of dart <smile>. +1 to making + go away completely.

Minor suggestion. I would have found it easier to find the new spec rules if both + and ! were defined in the same clause either under prefixExpression or unaryExpression.