Skip to content

Design Meeting Notes, 6/9/2017 #16415

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Stricter generic signature checks

  • Already did some work in Infer from generic function return types #16072 to perfom type argument inference using the return type of a signature as a target.
  • In Contextual generic function types #16305 we added support for signatures to gain type parameters from their contextual types.
    • This behavior is more appropriate because it respects the constraints and the universality of each usage of type parameters.
  • To follow up with this, we're introducing stricter generic signature checks (Stricter generic signature checks #16368).
    • Previously, when relating type parameters, we would erase them with the type any.
    • This was fairly unsafe.
    • Previously the following would work, but with Stricter generic signature checks #16368, the following is an error.
      type A = <T, U>(x: T, y: U) => [T, U];
      type B = <S>(x: S, y: S) => [S, S];
      
      function f(a: A, b: B) {
          a = b;  // Error
          b = a;  // Ok
      }
    • This is kind of a form of unification between the two parameters.
      • We infer using the type parameters of the target, as if we were calling the source with the target's parameters.
        • In other words, in a = b above, it simulates calling b with a's parameters.
    • The caveat is that this logic is only applied to single-signature types.
      • Any times you have overloads, it becomes extremely difficult to perform these checks.
  • So the question is: do we put this behind a flag?
    • Most errors are good, but it's hard to figure out what to do for some advanced scenarios.
    • Get it into master and see what we can work with.

Private Slots

Proposal: https://github.com/tc39/proposal-private-fields/ (Permalink)

Repo: https://tc39.github.io/proposal-private-fields/

  • How does this work with existing modifiers?

  • Can we offer a true downlevel translation?

    • To ES5?
      • No.
      • Need weakmaps
    • Yes above ES6.
  • Could give a mangled name in ES5/ES3.

    • Has potential problems.
      • Proxies, enumeration, etc.
        • Proxies and the like don't exist in ES5.
        • Best effort might be fine.
  • What about using Symbols in ES6?

    • Symbols aren't truly private - can be used by proxies, can be iterated over, etc.
  • Weakmaps make it truly private.

    • Are they performant?
      • Concerns over the type of GC pressure it may cause.
      • Edge is good at this!
        • Implementation is that every object has a list of weakmaps so that the lookup is inverted.
      • Others not as much at this point in time.
        • But will eventually improve!
    • But it's all opt-in.
    • Is it possible that all users really want is design-time private?
      • There are definitely people who've wanted private state.
  • P.S. everyone hates the syntax. we're not big on the syntax

  • Completely unrelated

    • The proposal breaks JScript 5.8 in IE 8.
      • ¯\_(ツ)_/¯
  • We'll all need to go over the FAQ more closely on the private state proposal repo.

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