Repository navigation
Resulting type of the object literal #16130
Description
Activity
This is a place for reporting and discussing issues, not a help forum.
Draqir LTD (@Draqir) first of all I have asked the question before at stackoverflow and haven't got an answer.
Specification are situated in this repo and what specification states may be considered as an issue.
Maybe there is some contradiction in spec, but more likely it is my misunderstanding, it is like I suspect an error in code but code works like intended.
If my question won't be answered then no problems I'll understand this.DanielRosenwasser commented
on May 30, 2017 MemberMore actionsFirst of all, the spec is definitely not up to date (it currently describes 1.8).
Is there any places in code where I can see resulting type of object literal in action?
declare function f<T extends { [x: string]: boolean | string | number }>(x: T): T; export let x = f({ a: 100, b: 200, c: 'hello' })
Hover over the type of
x(or get its--declarationemit.The type of
stris union of string literals and there is no branch for this case above.This is mostly a symptom of the spec being out of date. With indexed access types, we changed a lot of the behavior here. Check out #11929 for specifics.
- addedQuestionAn issue which isn't directly actionable in codeAn issue which isn't directly actionable in code
on May 30, 2017 Daniel Rosenwasser (@DanielRosenwasser) thanks for example.
If you are taking about
xvariable inletdeclaration then tsc shows me the object type likeexport declare let x: { a: 100; b: 200; c: "hello"; };
If you are talking about
xparameter offthen the type is like inextendsclause{ [x: string]: boolean | string | number }Let me make parsing of your example applying next section of spec to understand terms in the same way:
When an object literal is contextually typed by a type that includes a string index signature, the resulting type of the object literal includes a string index signature with the union type of the types of the properties declared in the object literal, or the Undefined type if the object literal is empty
Object literal is
{ a: 100, b: 200, c: "hello" }
Contextually typed by a type is{ [x: string]: boolean | string | number }
The resulting type of the object literal includes a string index signature with the union type of the types of the properties declared in the object literal is{[key:string]:number|string}
If I made parsing right then I have to expect the type ofxvariable as{[key:string]:number|string}and it solves my case and infers from spec.Daniel Rosenwasser (@DanielRosenwasser)
Now I see that resulting type of object is hidden (computed in background to compare it to contextually typed by a type ).
The goal of computing of resulting type of object to compare it to index signature type (if any exists) for validity.
To compare only, not to redefine previous type.
Maybe it is better to focus attention on the purpose of resulting type of object in spec.
And we can't see resulting type of object in the code.
We can see duality of behavior of object literal expression from your example.
Insideflocalxhas type{ [x: string]: boolean | string | number }.
Variablexhas type{ a: number, b: number, c: string }.
More than this we have third type - resulting type of object is{ [x: string]: string | number }in the background.https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L13412
const result = createAnonymousType(node.symbol, propertiesTable, emptyArray, emptyArray, stringIndexInfo, numberIndexInfo);
- locked and limited conversation to collaborators
on Jun 14, 2018
I asked question about resulting type of the object literal at stackoverflow.
From specification:
When an object literal is contextually typed by a type that includes a string index signature, the resulting type of the object literal includes a string index signature with the union type of the types of the properties declared in the object literal, or the Undefined type if the object literal is empty
First, it sounds like some entity that has type can redefine it if it meets object literal.
Second, maybe it is all about hidden conversations at expression trees?
The question:
Is there any places in code where I can see resulting type of object literal in action?
I have got an answer:
Ok.
I look at following part of spec.
A bracket notation property access of the form
object [ index ]
where object and index are expressions, is used to access the property with the name computed by the index expression on the given object. A bracket notation property access is processed as follows at compile-time:
If index is a string literal or a numeric literal and object has an apparent property (section 3.11.1) with the name given by that literal (converted to its string representation in the case of a numeric literal), the property access is of the type of that property.
Otherwise, if object has an apparent numeric index signature and index is of type Any, the Number primitive type, or an enum type, the property access is of the type of that index signature.
Otherwise, if object has an apparent string index signature and index is of type Any, the String or Number primitive type, or an enum type, the property access is of the type of that index signature.
Otherwise, if index is of type Any, the String or Number primitive type, or an enum type, the property access is of type Any.
Otherwise, the property access is invalid and a compile-time error occurs.
The type of
stris union of string literals and there is no branch for this case above.And I didn't see any index signatures in the example (from answer).
But it does compile.
Could someone elaborate on this topic, please.