Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Improved type inference for object literals#19513

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
ahejlsberg merged 18 commits intomasterfromstrictObjectLiterals
Oct 29, 2017

Conversation

@ahejlsberg
Copy link
Member

@ahejlsbergahejlsberg commentedOct 26, 2017
edited
Loading

This PR improves type inference for multiple object literals occurring in the same context. When multiple object literal types contribute to a union type, we nownormalize the object literal types such that all properties are present in each constituent of the union type. For example:

constobj=test ?{text:"hello"} :{};// { text: string } | { text?: undefined }consts=obj.text;// string | undefined

Previously we inferred type{} forobj and the second line subsequently caused an error becauseobj would appear to have no properties. That obviously wasn't ideal.

The key insight behind this PR is that forobject literal types we know that unspecified properties always have the valueundefined. This is unlike regular object types where unspecified properties might have any value. Based on this fact we implement the following new rules:

  • When checking a type relationship between a source type S and a target type T, if T is an object literal type, any excess properties in S are required to have typeundefined (normally such excess properties are permitted to have any type).
  • When widening a union type, we normalize all constituent types originating in object literals by adding optional properties of typeundefined to each constituent as appropriate such that all constituents have the same set of property names.
  • When inferring multiple object literal types for a type parameter, the object literal types are normalized into a single inferred union type.

An example of object literal normalization:

// let obj: { a: number, b: number } |//     { a: string, b?: undefined } |//     { a?: undefined, b?: undefined }letobj=[{a:1,b:2},{a:"abc"},{}][0];obj.a;// string | number | undefinedobj.b;// number | undefined

Nested object literals are likewise normalized:

// let obj: { kind: string, pos: { x: number, y: number, a?: undefined, b?: undefined }} |//     { kind: string, pos: { a: string, x?: undefined, y?: undefined, b?: undefined } | { b: number, x?: undefined, y?: undefined, a?: undefined }}letobj=[{kind:'a',pos:{x:0,y:0}},{kind:'b',pos:test ?{a:"x"} :{b:0}}][0];obj.kind;// stringobj.pos;// { x: number, y: number, a?: undefined, b?: undefined } | { a: string, x?: undefined, y?: undefined, b?: undefined } | { b: number, x?: undefined, y?: undefined, a?: undefined }obj.pos.x;// number | undefinedobj.pos.y;// number | undefinedobj.pos.a;// string | undefinedobj.pos.b;// number | undefined

Multiple object literal type inferences for the same type parameter are collapsed into a single normalized union type:

declarefunctionf<T>(...items:T[]):T;// let obj: { a: number, b: number } |//     { a: string, b?: undefined } |//     { a?: undefined, b?: undefined }letobj=f({a:1,b:2},{a:"abc"},{});obj.a;// string | number | undefinedobj.b;// number | undefined

Fixes#19236.

j-oliveras, danvk, NoelAbrahams, chrisgervang, xorets, jeremistadler, huy-nguyen, isao, Bnaya, CurlerRoo, and 25 more reacted with thumbs up emojisean-vieira, j-oliveras, bradleyayers, aciccarello, olaf89, chrisgervang, jeremistadler, Swatinem, isao, zigomir, and 10 more reacted with hooray emojifbartho reacted with heart emoji
@mhegazy
Copy link
Contributor

files#19613 to track that.

@RafaelSalguero
Copy link

Does this PR also fixes#19843?

Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

@RyanCavanaughRyanCavanaughAwaiting requested review from RyanCavanaugh

@mhegazymhegazyAwaiting requested review from mhegazy

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@ahejlsberg@mhegazy@RafaelSalguero

[8]ページ先頭

©2009-2025 Movatter.jp