Skip to content

Design Meeting Notes, 2/15/2023 #52790

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
andrewbranch opened this issue Feb 15, 2023 · 0 comments
Closed

Design Meeting Notes, 2/15/2023 #52790

andrewbranch opened this issue Feb 15, 2023 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@andrewbranch
Copy link
Member

andrewbranch commented Feb 15, 2023

Prefer using enum literal's own base type rather than enum's base type in comparison

#52703

  • New rules on relational operators prevent this, but seems like you should be able to do it
  • Agreement on expected behavior, some implementation nits to be discussed offline

Suggestion: error when using relational operators on types whose valueOf() method returns 'never' or 'void'

#52773

  • 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.

API Requests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants