Skip to content

Design Meeting Notes, 6/11/2021 #44555

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions