You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compelling use case: some objects in the Temporal API have a valueOf that throws (to prevent unreliable comparisons) (allegedly)
What’s the behavior when comparing things that are unions? Could a never return type fall out in union reduction, losing the info that comparisons should be illegal?
What type should we actually use for this? never implies throwing, but would void or unknown imply unobservability enough to merit an error?
Should we type the parameter list of valueOf as never to indicate it indicate it shouldn’t be callable, rather than checking the return type?
Is it really a huge deal if we lose some of these checks to union reduction? A best-effort seems ok here.
We don’t currently look at toString or valueOf for coercions. Should we special-case these Temporal objects?
People will be using polyfill types / augmentations for a long time, so we couldn’t just special-case by declaration in lib files.
How many special cases / incorrectly typed valueOf would we find? Seems like it could be sketchy.
Throwing doesn’t make a function return type inferred as never; you have to annotate it. It would return void as written in the example.
Comparibility is pretty weird/broken already.
Comparison isn’t actually special here—unary + is another example. "" + foo, unless toString is implemented too. Would we need to error there too?
Any attempts to unify this are doomed to fail because of Date. That’s why we haven’t tried something like this earlier.
A concern is breaking comparisons of userland objects that have a valueOf at runtime but don’t write types for them. So, you could imagine a mode where we only prohibit comparisons where valueOf is specifically marked as bad, or you could imagine a stricter mode where we only allow comparisons (between objects) where a valueOf explicitly returns a primitive.
Not sure this proposal has value if we’re only narrowly trying to prohibit never-marked valueOf comparisons, but doing the stricter option seems super breaky.
We have RWC test data on this—mostly just moment and stuff like that broke
Seems like any solution should prvent you from comparing / multiplying two array literals
It seems like this could be hard to explain to people, so maybe a syntactic marker for “this type is not coercible” would be easier to understand.
The interplay between valueOf, toString, and [Symbol.toPrimitive] is incredibly complicated.
Prefer using enum literal's own base type rather than enum's base type in comparison
#52703
Suggestion: error when using relational operators on types whose valueOf() method returns 'never' or 'void'
#52773
valueOf
that throws (to prevent unreliable comparisons) (allegedly)never
return type fall out in union reduction, losing the info that comparisons should be illegal?never
implies throwing, but wouldvoid
orunknown
imply unobservability enough to merit an error?valueOf
asnever
to indicate it indicate it shouldn’t be callable, rather than checking the return type?toString
orvalueOf
for coercions. Should we special-case these Temporal objects?valueOf
would we find? Seems like it could be sketchy.never
; you have to annotate it. It would returnvoid
as written in the example.+
is another example."" + foo
, unlesstoString
is implemented too. Would we need to error there too?Date
. That’s why we haven’t tried something like this earlier.valueOf
at runtime but don’t write types for them. So, you could imagine a mode where we only prohibit comparisons wherevalueOf
is specifically marked as bad, or you could imagine a stricter mode where we only allow comparisons (between objects) where avalueOf
explicitly returns a primitive.never
-markedvalueOf
comparisons, but doing the stricter option seems super breaky.moment
and stuff like that brokevalueOf
,toString
, and[Symbol.toPrimitive]
is incredibly complicated.API Requests
getStringLiteralType
/getNumberLiteralType
any
types.isAssignableTo
.bigint
is missing.getCompletionsAtPosition
to expose completionsymbol
information #52560The text was updated successfully, but these errors were encountered: