Skip to content

Design Meeting Notes, 9/24/2024 #60284

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

Open
DanielRosenwasser opened this issue Oct 18, 2024 · 0 comments
Open

Design Meeting Notes, 9/24/2024 #60284

DanielRosenwasser opened this issue Oct 18, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Always Report useDefineForClassFields-Related Errors

#59623

  • When a dev writes a parameter property and a class field depends on the parameter property, we error under useDefineForClassFields (or if implicitly in a newer target).
  • We want to issue the error regardless of the target.
  • We like the idea but it could cause a lot of issues. No code fix today which makes it harder.
  • We will just deprecate useDefineForClassFields in 6.0.
  • Should clarify what the plan is for this (@RyanCavanaugh) - is the idea that we just flip the emit and errors over in 6.0 and let people set useDefineForClassFields+ignoreDeprecations until 6.5?

Perform subtype reduction on call expression types if type argument arity fails

#60036

  • Let's imagine Array<T> | ReadonlyArray<T>.
  • They both have the same reduce method overloads. Two of them are considered identical, but one generic signature which is the same isn't surfaced because we don't consider common methods as identical.
    • So if you write reduce<...>(...), that'll fail.
  • The idea here is that if you write a type argument and it doesn't match any signature's arity, the checker will subtype-reduce the expression type and try again.
  • Seems very special-casey.
  • Why are you writing Array<T> | ReadonlyArray<T>? Why not just write ReadonlyArray<T>?
  • One weirdness here is the fact that you need to provide type arguments for this to kick in. This is a little bit ad-hoc and makes it hard to reason about. As a user, you wouldn't necessarily expect type arguments to trigger any special behavior.
    • Array.prototype.reduce is a pretty special case and
  • Maybe there should be a special rule about Array<T> | ReadonlyArray<T> being reduced appropriately?
  • We have other special-cases around arrays, why is this one bad?
    • Those were not ideal, but they were motivated by common pain-points around operating on arrays. The issue this addresses doesn't have a lot of feedback other than the current report.
  • For now we've decided not to pursue this change.
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

1 participant