Design Meeting Notes, 6/9/2017

[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?

  • See Compatibility with ECMAScript Private Fields proposal #16324 (comment)

• 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.

  • https://github.com/tc39/proposal-private-fields/blob/master/FAQ.md

[kitsonk]

Just a comment with the ES5 down-emit with private members, if you considered the async/await down emit pattern by assuming WeakMap it would be nice to have the down-emit and have those of us stuck in ES5 provide the polyfill.

[kitsonk]

Also from a @dojo perspective we have debated a lot of putting private state in weak maps. We just know that if it is accessible, people will abuse it and the only way to to ensure it to promote it being truly private. The biggest challenge is that we have in some cases run into having to name privates in descendent classes silly things because of private member name conflicts, which makes code unclear.

[kitsonk]

And P.S. I hate the syntax for the record too... 😂

[littledan]

Hey, thanks for the feedback about the syntax. The rationale is documented in the FAQ. Does anyone have any other suggestions?

The proposal breaks JScript 5.8 in IE 8.

What's the concern here?

[styfle]

@littledan The FAQ doesn't address why the octothorpe (#) sigil was chosen.

I would think the js community would prefer the underscore (_) which is a popular convention used to denote private member variables in current code as well as python and other languages.

[kitsonk]

I would think the js community would prefer the underscore (_) which is a popular convention used to denote private member variables in current code as well as python and other languages.

The problem is that would break the internet, because the runtime engine must lookup the property differently. If every _foo suddenly became truly private, imagine the horror. The sigil must be something that isn't currently a valid identifier in JavaScript to ensure that nothing breaks.

[littledan]

@styfle This is a great point. I added a new FAQ entry to explain the reasoning.

[styfle]

@littledan Excellent, thank you for the detailed write up! I submitted a PR with some typo fixes.

I noticed the proposal-private-fields is Stage 1 but the proposal-class-fields is Stage 2 and seems to include private fields. Is this expected and if so, why?

[mihailik]

Why WeakMaps not closures?

[littledan]

@mihailik Because there's still just one method identity on the prototype, rather than the instance.

[mihailik]

A rough prototype (play with it on CodePen)

function Apple() {
  
  // carrying private state
  function Private() {}
  Private.prototype = this;
  var private = new Private();
  
  // bind methods to private state
  this.getColor = private.getColor.bind(private);
  this.setRed = private.setRed.bind(private);
  this.setGreen = private.setGreen.bind(private);
}

Apple.prototype.setRed = function() {
  this._color = 'red';
  this.constructor.prototype.caption = 'Red Apple'; // mutating of public state, a bit convoluted
};

Apple.prototype.setGreen = function() {
  this._color = 'green';
  this.constructor.prototype.caption = 'Green Apple'; // mutating of public state
};

Apple.prototype.getColor = function() {
  return this._color;
};

var s = new Apple();
s.setRed();
console.log('setRed: ', s.getColor(), s.caption, s._color);
s.setGreen();
console.log('setGreen: ', s.getColor(), s.caption, s._color);

s.caption = 'Orange Apple?';
s._color = 'orange';
console.log('mutating directly: ', s.getColor(), s.caption, s._color);