Design Meeting Notes, 2/3/2017

[DanielRosenwasser]

private and protected members in mixin classes

Now that you can derive from intersection types and arbitrary object types, the world "is not as simple as it used to be."

Example: let's say you take an intersection of some class type and some other type.
You do want protected members to be visible in the new subclass.

When deciding whether two things are assignable, discerning private members is not insanely hard because we can always jump back to the originating declaration of a property.

But for protected, things seem less simple in terms of implementation.
If one thing "derives" from the other, the two should be assignabe.
However, it's become murky what the definition of "assignable" should be.

But at least protected-ness is maintained.

We are working on some rules, but it looks like the system will be "defeatable".

Question: What happens if you intersect a private & protected?
Answer: Becomes protected - greater visibility always wins.

Making JavaScript Transition Easier

• Took a couple of available JS codebases

• We looked at turning TS errors on in those codebases.

• Things that came up:

  • A couple of .d.ts file issues. - (easily fixable) (Allow quoted names in ambient contexts #9846)
  • Using arguments should imply rest arguments (...args) - (easily fixable).
  • Tacking properties onto a newly-constructed object.
    • Tough: how do you know when an object is finished?
  • Under strictNullChecks, initializing a value with null makes it "stick" around as null.
    • Useless.
  • Empty array gives you never[].
    • Doesn't evolve because it's initialized in the constructor.
    • Indirectly initialized.
    • Actually, looks like a bug.
      • never[] should never pop up anymore!
      • "never say never!" - @aozgaa
      • Looks like JS constructor inference logic.

• Problems with JSDoc.

  • Scarce!
  • "Well you're gonna have a bad time without types." (paraphrased)
    • Not true! There's ways to do better!

• Expando pattern is definitely one of the most prevalent patterns we see.

  • Possible to do this.

• We want to ensure that the experience gives helpful errors and not noise.

  • Then we can decide to refine the experience and recognize the appropriate patterns.

• The choices we make here are hard - comes down to whether we want to provide an experience where the user says "this code is correct" vs "please tell me whether this code is incorrect".

• Idea: do a difference inference process for variables local to function declarations.

  • Similar to how we do constructor inference for property assignments on this.
  • Bind-time analysis?
    • Possibly.