Skip to content
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

Design Meeting Notes, 6/11/2021 #44555

Closed
DanielRosenwasser opened this issue Jun 11, 2021 · 3 comments
Closed

Design Meeting Notes, 6/11/2021 #44555

DanielRosenwasser opened this issue Jun 11, 2021 · 3 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Decorators on Class Expressions

#42198
#44237 (comment)

  • Goes against the policy we've had of investing more in decorators until progress
  • Really wary of doing anything with decorators until we get a major update with major support on the proposal.
  • Every feature adds
    • size to the compiler
    • potential bugs
  • More complexity and logic that we're stuck with over time.
  • "Stop digging the hole."
  • There are workarounds, so we suggest that in the meantime.
  • Parsing without "support"?
    • Well now we have to do parsing.
    • Don't know what that will look like.
  • Conclusion: again, don't touch decorators until the proposal progresses.

Correcting Receivers on Calls

#35877

  • Had to back out this change because it affects every single function call on every imported function.
    • foo.yadda() -> (0, foo.yadda)()
  • Doesn't really impart a runtime performance cost, it imparts a compile-time performance cost.
  • Tried to reuse a lot of nodes, still have to create a lot of new parenthesized nodes.
  • Settled on "put it behind a flag".
    • Haven't gotten a lot of negative feedback because a lot of people have been using esnext and a bundler.
  • Similar to someFunc.name.
  • Would be nice to have a level of preference around spec corner cases.
    • ?. and ?? are unnecessarily complex for most users.
  • Had several ideas around removing the performance cost.
  • "Strict mode" like Babel's "loose mode"?
    • Babel uses different transformations to do loose mode.
    • We're more coarse-grained than that for the most part.
    • No reason we have to architect it that way.
  • Configurability would be great.
    • ?. or ?? emit makes us upset.
    • Does this matter in the world of evergreen?
      • ES3 is deadish
      • ES5? Less clear.
    • downlevelIteration
    • useDefineForClassFields
  • The current discussion positions TypeScript as "runtime breakage" - but changing the existing behavior is actually runtime breakage if you're relying on TS.
  • Conclusion
    • Try to avoid a flag.
    • If not, come up with a consistent flag naming convention.
      • specEmitReceiver? 😖
      • specEmit* as a prefix really is the higher order.
      • strictEmit?
@canonic-epicure
Copy link

Very frustrated about the decorators decision. I do understand your reasoning though.

Just curious - the same problem will remain with the emerging ES decorators spec? It will also not be possible to use ES spec decorators in class expressions? It feels like this PR is actually future-proof.

Personally for me this decision means I'll have to stick with the abandoned TS branch, you can imagine what it's like. And thing is, a workaround for this issue exists, but it breaks the declaration files generation. Shouldn't that be addressed finally.

@canonic-epicure
Copy link

Perhaps the #42198 PR was closed prematurely. Better to keep it may be, because if the ES spec will say decorators are applicable for class expressions, it can be re-used. Otherwise someone will have to repeat the work already done.

@RyanCavanaugh
Copy link
Member

Closed PRs aren't deleted; it isn't really scalable to have an open PR for every feature that might possibly exist.

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

3 participants