Activity

1. jcalz commented on Mar 21, 2021

   

   Joe Calzaretta (jcalz)

   on Mar 21, 2021

   Contributor

   More actions

   I doubt they will think this is a bug; the name property of a function/class constructor is indeed of type string. You might want to consider filling out the feature request template instead of the bug report template.

   Is this a dupe of #1579 maybe?

   👍React with 👍1Reacted by Alice T'Poteat

   ❤️React with ❤️2Reacted by Martin Johns and Alice T'Poteat
2. poteat commented on Mar 21, 2021

   

   Alice T'Poteat (poteat)

   on Mar 21, 2021

   Author

   More actions

   Oh, that would be a much stronger feature, assuming nameof in a type context would return a literal string type. I do think though that generally that types associated with class names should be inferred narrowly, for the same reason that:

   const foo = "foobar";
   
   foo // Type is "foobar" because `foo` was defined to be const.
3. jcalz commented on Mar 21, 2021

   

   Joe Calzaretta (jcalz)

   on Mar 21, 2021

   Contributor

   More actions

   #4628 and #3841 highlight some of the issues surrounding the static side of classes. With the notable exception of the construct signature itself, the static side of a class is inherited by subclasses, and thus forms a type hierachy:

   class Foo {
     static someStaticProp = "Foo";
     a = 1;
   }
   
   class Bar extends Foo {
     b = 2;
   }
   
   Bar.someStaticProp; // exists
   
   let fooCtor: typeof Foo = Bar; // okay
   
   class Baz extends Foo {
     // construct signature incompatible with Foo
     constructor(public c: number) {
       super()
     };
   }
   fooCtor = Baz; // error

   If the name property of a class constructor (or function) were to be strongly typed in the way you're asking for, then subclass constructors would never be assignable to superclass constructors (so let fooCtor: typeof Foo = Bar would be an error) and this would undoubtedly break quite a bit of real world code (this is one reason why I'm suggesting that you fill out the feature request template, as it asks you to consider such things).

   At least the nameof feature wouldn't necessarily require subclass constructor compatibility to break.

   ❤️React with ❤️1Reacted by Martin Johns
4. poteat commented on Mar 21, 2021

   

   Alice T'Poteat (poteat)

   on Mar 21, 2021

   Author

   More actions

   Thanks Joe Calzaretta (@jcalz) - I did not consider that.

   I'm closing this out in lieu of #1579, as the current proposal above is unworkable (breaking changes is not my vision)
5. Alice T'Poteat (poteat)

   closed this as completedon Mar 21, 2021
6. microsoft

   locked as resolved and limited conversation to collaborators on Oct 21, 2025