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, 11/3/2017 #19722

Closed
DanielRosenwasser opened this issue Nov 3, 2017 · 0 comments
Closed

Design Meeting Notes, 11/3/2017 #19722

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

Comments

@DanielRosenwasser
Copy link
Member

Stricter Tuple Types

#17765

  • Tried freshness, generally encountered strange behavior.
  • Adding an explicit length property breaks fairly little
    • Things we catch:
      • Accidental Haskell-style list syntax: [T] instead of T[].
        • This is actually a singleton tuple of T instead of Array<T>
        • Caught ~10 instances of that.
    • Actual errors where people misunderstood the API
      • Found this in Highcharts & Leaflet
    • Downside is you can't cast between these anymore without an intermediate.
    • One break in firebase-js-sdk
  • Then we tried changing tuples to extend ReadonlyArray instead.
    • Which makes tuple elements immutable which is more debatable.
    • And problematically means you can't assign to array
    • Didn't find many errors outside of the test suite.
    • Added another break in firebase-js-sdk
  • What about push: never; pop: never;?
  • Conclusion: try out the stubs, keep testing on real world code.

instanceof checks

#19671

  • Idea: instanceof has worked structurally since forever with us.
    • But because of structural compatibility, things that were structurally identical would act very strangely.
    • We want to change this to actually check the base types as it does at runtime.
  • Things the PR does
    • Makes instanceof nominal

    • Changes to subtype reduction to accomodate this new behavior.

    • Take the following:

      class A {}
      class B extends A {}
      
      class Q extends A { qProp: any; }
      
      let blah = Math.random() ? new B() : new Q();
    • Under old subtype reduction behavior, blah has type B; means the negative check for blah instanceof B gives you never:

      if (blah instanceof B) {
          blah; /* has type `B` */
      }
      else {
          blah; /* has type `never` */
      }
    • Under new behavior, we aren't as agressive; blah has type B | D

      if (blah instanceof B) {
          blah; /* has type `B` */
      }
      else {
          blah; /* has type `D` */
      }
    • This is better, but it affects things like callability.

  • Do we care about how ES2015 allows this behavior to be overridden with Symbol.instanceOf?
    • Most people just don't do this.
  • It's in nightly now.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Nov 3, 2017
@mhegazy mhegazy closed this as completed Nov 3, 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

2 participants