Cannot perform arithmetic on Dates

[bcherny]

new Date() - new Date()
// [ts] The right-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

JS will implicitly convert these to numbers via valueOf, so explicit conversion is not necessary.

[Arnavion]

Duplicate of #8260

[bcherny]

@Arnavion It doesn't seem fair to close #8260. Implicits for built in types are a key part of the ES1 spec, and should at some point be implemented by TS. It can be prioritized lower than other things, but it should not be ignored.

[Arnavion]

It's not being ignored, it's omitted by design. Implicit conversions are the source of bugs. If all valid ES was valid TS there would not be much point to TS.

If one really wants to subtract dates then that issue shows how to convince the compiler to allow it.

[bcherny]

Is there a design document, or something else that talks about this idea? Are there other parts of the ES spec that TS chose not to implement?

Implicits are understandably notorious for causing bugs in dynamically typed languages (as are almost all language features :)), but they are a core part of many statically typed languages (C#, Scala, Haskell), so it seems silly to omit them. Especially if you want to work with JS code in the wild, which uses toString, valueOf, and toJSON implicitly all the time.

[nippur72]

@bcherny the "design document" is TypeScript Design Goals which says:

1. Statically identify constructs that are likely to be errors.

which I think applies the case of Date subtraction.

[bcherny]

How do you plan on interoperating with existing, JSDoc'd code if the compiler doesn't understand implicits?

[aluanhaddad]

Consider

new Date() - new Date() // 0

That output is reasonable
But consider

var d = new Date();
d.setHours(3);
d - new Date() // -43218751
d + new Date() // "Sat Jun 25 2016 03:51:22 GMT-0400 (Eastern Daylight Time)Sat Jun 25 2016 17:54:37 GMT-0400 (Eastern Daylight Time)"

This is really weird behavior and I don't think it should be encouraged.

[bcherny]

@aluanhaddad Encouraging/discouraging behavior should be left to tslint, I think.

TypeScript should first and foremost understand the rules of the ES specs, and help TS and existing JS code scale given those rules. If there's a whole bunch of existing JS code that TS is unable to infer and flow types for, that makes TS less valuable to a lot of developers!

[aluanhaddad]

@bcherny in principle I absolutely agree with that statement. I oppose proposals that would fundamentally change the semantics of JavaScript and proposals which did not map intuitively to JavaScript.
However, JavaScript places no restrictions on the subset of values to which arithmetic operators can be applied. It's perfectly valid to add and subtract arbitrary objects, but these operations, while having well-defined semantics, are often absurd. In this case the subtraction of two values results in a number, but their addition results in a string. That doesn't seem to make a whole lot of sense and forms a subtle trap when changing the order of operations.

[RyanCavanaugh]

@bcherny nearly everything TypeScript flags as an error has some valid runtime interpretation. If you want to use [ ] * { } as a way to produce NaN, well, that's according to spec, so TypeScript shouldn't disallow it?

This is really a dupe of #2361 because Date implements valueOf that sometimes returns number.

[aluanhaddad]

@RyanCavanaugh thank you for calling date insane, that's really what I was trying to say, only you did so much more concisely ❤️

[bcherny]

@aluanhaddad I agree that JS implicits can lead to subtle bugs!

@RyanCavanaugh There's an argument to be made that if someone writes:

let a: number = [ ] * { }

The TS compiler should be OK with it, since this is valid JS, and TS is a superset of JS. If someone then tries to do something with a assuming that it's, say, an array, the TS compiler should warn that "hey! this is actually a number!". If you consider this bad style, then create a tslint rule for it for your project.

Anyway, to wrap up it sound like what you guys are saying is "TS is ok with some implicits (eg. conversion to boolean via logical operators like ! or &&), but not others (eg. conversion to number via arithmetic operators like + or -), because the former are used idiomatically in JS, while the latter are mostly a source of bugs".

[RyanCavanaugh]

That's basically correct. The unary + / - operators are relatively hard to use incorrectly.

The real problem with Date is that its implicit conversion rules are just nuts. x - 0 is a number, x + 0 is a string, and (x + 0) * 1 is NaN ? It's a loaded footgun.