Skip to content

Design Meeting Notes, 10/2/2017 #18895

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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.

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