Add emu-note about why valueOf throws

[justingrant]

js-temporal/temporal-polyfill#21 (comment) exposed an issue we should look at. The problem @12wrigja found is that when string interpolation is polyfilled by TS (and perhaps by Babel too?) it's converted to +, which per https://tc39.es/proposal-temporal/#sec-temporal.plaindate.prototype.valueof will throw.

throw new RangeError(Offset ${offsetStr} is invalid for ${dt} in ${timeZoneString}); is transpiled by tsc to throw new RangeError('Offset ' + offsetStr + ' is invalid for ' + dt + ' in ' + timeZoneString);, and the '+' operator invokes valueOf.

This implies that code using Temporal instances in string interpolations will work fine in native ES6 but will throw when polyfilled into ES5. Is this OK? If not, are there any ways around it (e.g. by using @@toPrimitive) ?

[ljharb]

Babel handles this properly with the strict transpilation, but not with the loose one.

This is a transpiler bug when present; it’s fixable by them and the proposal shouldn’t be concerned with it (beyond filing issues etc)

[justingrant]

@ljharb what is the "correct" transpilation behavior in this case?

[ljharb]

Wrapping it in String(), effectively - iirc Babel actually uses the String concat method to ensure proper spec semantics.

[gilmoreorless]

There's an open issue for TypeScript about this transpilation behaviour at microsoft/TypeScript#39744. I've added a comment about the Temporal use case there.

[12wrigja]

Speaking of the spec, would it be possible to elaborate on the spec why these objects throw in their valueOf methods? https://tc39.es/proposal-temporal/#sec-temporal.plaindate.prototype.valueof isn't particularly informative.

[ptomato]

Meeting, August 5: the reasoning for valueOf throwing might be a good thing to add in an <emu-note>.

[justingrant]

FYI, I opened a PR against React to fix the problem there.

I'm starting to worry that this behavior will cause a lot of problems in the wild, given how often we've seen it so far with mainstream platforms. If we decided to not throw in valueOf, what bad things would happen?

[ptomato]

The discussion is in #517. (tl;dr: if you include a valueOf, then people will use < and > whether we like it or not. If valueOf returns the same thing as toString, then this will "work" in some cases, not in other cases, but enough of the time to be dangerous.)

The new angle here is actually not that people are using comparison operators, but that they are (indirectly, via a library or a transpiler) using the + operator for string concatenation which first consults valueOf instead of toString. My opinion is that libraries that do this are going to be broken for other cases, not just Temporal objects, so it's actually good if this surfaces and causes bugs in libraries to be fixed, which would otherwise remain latent.

In the thread in #517 there was another suggestion: having valueOf return a primitive type (likely a BigInt) such that the comparison operators always worked. The disadvantage of this was that cross-type comparisons, e.g. instant > plainDate would succeed but produce a nonsense result. For the string concatenation problem, I think it would actually make the problem worse, because you'd get wrong strings instead of exceptions, so it would still be broken but less obviously.

(For example, with the TypeScript bug, you'd get something like this:)

date = new Temporal.PlainDate(1970, 1, 1);
console.log(`The date is ${date}`);
// JavaScript: The date is 1970-01-01
// TypeScript: The date is 0

[justingrant]

Another detail to add: one of the reasons for < and + to throw is that it'd leave space for a better implementation if JS ever supported overloaded operators in the (distant?) future.

[ljharb]

I would not hold my breath for that to work out smoothly.

[12wrigja]

I think this can be marked as fixed given that both Babel and TypeScript now handle this correctly - TS is fixed as of v4.5.

[ptomato]

I think there was still a pending action to add an <emu-note> to each valueOf() algorithm explaining why it needs to throw.