No warning when using unary +/- operators on functions and objects?

[jcalz]

TypeScript Version: 2.6.1

Code

let func = () => "func";
+func; // no error
-func; // no error

let obj = { foo: "bar" };
+obj; // no error
-obj; // no error

Expected behavior:
Unary + or - is only applicable to a number or maybe a string. I would expect the lines listed as // no error to be errors.

Actual behavior:
Unary + and - never generates a warning no matter what crazy stuff I try to apply it to.

---

I was made aware of this behavior by a recent Stack Overflow question. I see from #7019 that unary + and - on strings is supported, and I guess I can understand that as a way to parse a string into a number (for +, anyway. Is - really used like this in practice?). But functions? objects? Seems more likely to be an error than intentional to me. Thoughts?

[calebsander]

It may not make much sense for anyone to ever use + or - on a non-primitive value, but it is not incorrect code. It will execute just fine, converting to a string, and then to a number (usually NaN). There is one use case I could could imagine: +[x], where x is a number or string, evaluates to +x. The + operator is equivalent to calling Number() on the value, and the signature of that function is (value?: any) => number, so + and - can technically be applied to any value.

Because JavaScript tries to make sense of a lot of operations that would cause other languages to throw an error, you could argue that TypeScript should prevent (or warn) you for many valid operations. For example, adding a string to a number? 1 + 2 + '3' similarly seems like a "crazy" application of the binary + operator, but it is perfectly valid. What about x / 0?

[jcalz]

Relevant reading about "not incorrect code" by @RyanCavanaugh:

• Stack Overflow FAQ-style Q&A: "What does 'all legal JavaScript is legal TypeScript' mean?"
• Comment in Microsoft/TypeScript#4002, isNaN and isFinite should accept number or string

I think the litmus test isn't usually "is this code invalid JavaScript" but "is this code likely to be a bug" (and whether the false positives you would get by flagging it as an error are preferable to the false negatives you would get by allowing it). JavaScript allows almost everything. TypeScript should warn you when you are doing something allowable-but-probably-wrong.

This issue is asking whether people really use unary + or - on non-string and non-number operands in practice enough to warrant supporting it. Who do we break by disallowing it, and should they be left alone or told to make their code more explicit by using +String(x) or -(x.toString()) or Number(x) when x is a function or an object?

[RyanCavanaugh]

Seems wrong when we can be reasonably confident that the result will be NaN. Operands should be of type number, string, Date, or boolean (am I missing anything?)

[sean-vieira]

As @calebsander points out, the single element tuple when it's value is number | string.

Also, any object that overrides Object.valueOf and returns either a string or a number:

var x = +({valueOf() { return '33'; }})  // 33

or toString and returns something that is a stringified number:

var x = +({toString() { return Math.random() > 0.5 ? '3' : 'abc'; } });  // sometimes 3 sometimes NaN

[jcalz]

If we intentionally disallow the single-element tuple and objects with valueOf() of toString() overrides, how much real-world code does that break? I obviously can't speak for everyone but I'd be happier being alerted for all of these:

var w = +({valueOf: ()=>''}); // 0
var x = +([{toString: ()=>'1'}]); // 1
var y = -([[[[[[[-2]]]]]]]); // 2
var z = +([{valueOf() { return 3; }}]); // 3

so I could either rewrite them or assert the quantity in parentheses as any to force the type check to succeed:

var w = +({valueOf: ()=>''} as any); // 0
var x = +([{toString: ()=>'1'}] as any); // 1
var y = -([[[[[[[-2]]]]]]] as any); // 2
var z = NaN; // not 3 

Hey, did you realize that z was actually NaN instead of 3? Neither did I.

[RyanCavanaugh]

I'm really skeptical that anyone uses - to pluck a coerced number out of a single-element array. Or + for that matter.

[RyanCavanaugh]

We agreed that the current behavior is dumb, but would prefer to group this change into an overall revamp of how the general numeric operators (especially > and <) work. The TL;DR of that is that we need the type system to special-case Date, both because of its idiomatic usage (+someDate is common) and wacky behavior (its preference of coercion to string vs number is different from all other objects)

[james-cnz]

I just came across this recently. I declared some strings across multiple lines, concatenated with +, and in one place accidentally put a + at the end of one line and the start of the next. I was very surprised that it got through type checking.

My feeling is that the unary +/- operators are a special case. I think semantically they really shouldn't be operators at all, but rather part of a numeric literal. I suspect they were only made into operators in the first place to make parsing easier.

[gcnew]

Parsing unary operators as operators is actually harder than treating them as part of the literal. However, if they weren't operators you wouldn't have been able to write let y = -x;.