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, 10/27/2017 #19536

Closed
DanielRosenwasser opened this issue Oct 27, 2017 · 2 comments
Closed

Design Meeting Notes, 10/27/2017 #19536

DanielRosenwasser opened this issue Oct 27, 2017 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Improved inference for object literals

#19513

  • When dealing with object literals, we know exactly what properties are present.
  • So the idea is: whenever fresh object literal types occur together in a union, we can factor them into a more well-understood type.
  • This new process is called object literal type normalization, and is performed during widening.
    • This means that if widening does not need to occur, normalization doesn't occur.
    • For example, if an explicit type is given, we don't need to widen, so we verify against the most exact version we start with.
// 'objs' has an element type of
//      { a: number, b: number } |
//      { a: string, b?: undefined } |
//      { a?: undefined, b?: undefined }
let objs = [ {a: 1, b: 2}, { a: "abc"}, {} ];
let obj = obj[randomInt()];
obj.a; // string | number | undefined
obj.b; // number | undefined
  • We need to look into this-types, since we don't use normalized properties in that context.
  • What about when you're in non-strictNullChecks mode?
    • If you have one object with color and another with colour, now both are available, whereas before you'd get {} which would eventually raise your own suspicions when you couldn't use the types.
    • Yes, it is a step backwards in this regard.
  • Why don't we just always include | undefined on properties that occur in a union of object types?
    • e.g.

      declare let a: {x: ''};
      declare let b: {};
      let objs = [a, b];
      objs[0].x // should this be 'string | undefined'?
    • No, you don't have a license to do this because the object types may have other properties that aren't listed; this only works with exact types.

  • This is techncally a breaking change because previously we would eventually infer {}.
    • That means anything was subsequently assignable.
    • Does that come up often? Is that even desirable?
    • Real world code didn't break at all.
  • What about in type argument inference?
    • Yes, we do the same thing now as well.
  • So given all of this work, do we want to continue even doing best-common-supertype inference? Why not just return a union?
  • Conclusions
    • Continue discussing union inference
    • Continue discussing non-inferential or lower-priority inference
    • Continue discussing whether we can introduce a way to specify whether inference produces a union vs a single BCT.
    • But overall 👍 on the PR as it is.

Better error spans in array literals

#19236

Tuple freshness & stricter tuple behavior

#19463

  • Maybe we should issue an excess array literal element error?
  • Okay, but why not error on length mismatches for all tuple types?
    • Have them have an explicit length property?
    • Maybe also have them derive from ReadonlyArray?
  • strictTupleTypes?
  • To be continued.
@unional
Copy link
Contributor

unional commented Oct 28, 2017

Was there a conversion on #12400?

As in the last meeting #19393 it says "Conclusion: continue next time on TypeScript Design Meeting Z"

@mhegazy
Copy link
Contributor

mhegazy commented Oct 30, 2017

Was there a conversion on #12400?

Not rely. the conclusion is we should tackle #12400 with #13195. and that one is a bit tricky.

@mhegazy mhegazy closed this as completed Oct 30, 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

3 participants