Keyof doesn't see all apparent members  #16578

Activity

1. ahejlsberg commented on Jun 16, 2017

   

   Anders Hejlsberg (ahejlsberg)

   on Jun 16, 2017

   Member

   More actions

   This is by design. The keyof operator only considers the declared or inherited properties of a type, not those that come from its apparent type.
2. Anders Hejlsberg (ahejlsberg)

   added

   By DesignDeprecated - use "Working as Intended" or "Design Limitation" insteadDeprecated - use "Working as Intended" or "Design Limitation" instead

   on Jun 16, 2017
3. olegdunkan commented on Jun 16, 2017

   

   olegdunkan

   on Jun 16, 2017

   Last edited by olegdunkan

   Author

   More actions

   Anders Hejlsberg (@ahejlsberg) ok, thanks.

   Would you mind if ask a question.
   Spec doesn't define a notion of the apparent type, only apparent members .

   From spec:
   The apparent members of the primitive type String and all string literal types are the apparent members of the global interface type 'String'

   I can assume from spec that the global interface String is a apparent type if so then the global interface type 'Function' is also a apparent type.

   For global interface String it works, but for the global Function doesn't !!!

   check("", "atChar");  //ok

   The question is what is the apparent type, what is a difference between String and Function and more interesting what is a motivation to differ (Number, String and Boolean) and (Object, Function) global interfaces in the context of the keyof type query?
4. olegdunkan commented on Jun 17, 2017

   

   olegdunkan

   on Jun 17, 2017

   Author

   More actions

   I have made some investigations.
   From tsc code follows that the apparent type of type T is {} except:
   for string is global interface String,
   for number is global interface Number,
   for boolean is global interface Boolean,
   for type parameter is constraint, if any,
   ...

   function getApparentType(type: Type): Type {
               const t = type.flags & TypeFlags.TypeVariable ? getBaseConstraintOfType(type) || emptyObjectType : type;
               return t.flags & TypeFlags.Intersection ? getApparentTypeOfIntersectionType(<IntersectionType>t) :
                   t.flags & TypeFlags.StringLike ? globalStringType :
                   t.flags & TypeFlags.NumberLike ? globalNumberType :
                   t.flags & TypeFlags.BooleanLike ? globalBooleanType :
                   t.flags & TypeFlags.ESSymbol ? getGlobalESSymbolType(/*reportErrors*/ languageVersion >= ScriptTarget.ES2015) :
                   t.flags & TypeFlags.NonPrimitive ? emptyObjectType :
                   t;
           }

   The motivation to differ (Number, String and Boolean) and (Object, Function) is probably to prevent enumerating of native (intrinsic) properties of Object and Function for user types.
5. olegdunkan

   closed this as completedon Jun 17, 2017
6. microsoft

   locked and limited conversation to collaborators on Jun 14, 2018