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, 10/2/2017 #18895

Closed
DanielRosenwasser opened this issue Oct 2, 2017 · 0 comments
Closed

Design Meeting Notes, 10/2/2017 #18895

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

Comments

@DanielRosenwasser
Copy link
Member

throw expressions

TC39 proposal: https://github.com/tc39/proposal-throw-expressions
PR: #18798

  • Already have a PR.
  • Current open problems:
    • Control flow analysis additions and reachability checks at the expression level.
  • Should we put this under experimental?
    • Like the idea of being able to actually experiment with behavior more openly before shipping, especially with a stable feature like this.
    • However, doing this and calling everything "experimental" may not give people a clear picture of how experimental any one feature is.
  • What about other statement level constructs?
    • Committee seems 50/50 on whether they want anything beyond control-flow constructs.
  • Conclusion: let's just wait on stage 3, it seems like we may reach consensus relatively soon.

ECMAScript private fields

TC39 Proposal: https://github.com/tc39/proposal-private-fields
Issue: #9950

  • Statics?
    • Ready but apparently issues?
  • Are declarations required outside the constructor?
    • Yes.
  • What about structural compatibility?
    • External to the class, these types are ostensibly the same.
    • What about methods that take other instances and use their privates?
    • Too complex; run-time private should give the same compatibility rules as design-time private.
    • Also,
  • Downlevel emit?
    • WeakMap down to ES2015?
      • But performance!
    • Name mangling?
      • But not really private.
      • Object.defineProperty to avoid enumerability?
    • The driving reason for this feature was hard private. Anything we do here should have hide privacy.
  • Conclusion: Explore performance of WeakMaps and WeakMap polyfills first?

Strict Function Types

#18654

  • Most recent change: only methods and constructor types are exempty from the check.
    • Causes more breaks, but makes more consistent & predictable behavior.
    • Hack to get back to bivariant mode (x: Foo) => Bar becomes { " bivariant method"(x: Foo): Bar }.
  • Also implementation resets errors after measurement checks when any type parameter was invariant.
    • Experimented with assertion-level syntax.
  • One thing we've seen is that finding out why types have become invariant becomes extremely difficult!
  • Problem: diff mapped type construct doesn't have appropriate variance measurements.
  • Let's get that in this afternoon.

Allow dynamic names

  • Let's try to get this into the RC.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Oct 2, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant