Typescript: Design Meeting Notes, 5/6/2016

[RyanCavanaugh]

• #8476 - Uninitialized non-null properties in classes
  
  
  
  • Definitely going to break _some_ code patterns
  
  
  • e.g. a separate init method
  
  
  • e.g. initialization is done in a factory method
  
  
  • e.g. initialization is done in a second call by the caller
  
  
  • We might end up with another commandline switch, which is not great
  
  
  • You may want this flag on some classes, but not others...
  
  
  • This gets weird in abstract classes
  
  
  • Have to check the whole lineage to see what happens
  
  
  • But it's a big hole
  
  
  • We could check that you assign to it _somewhere_... but that's weird
  
  
  • Workaround is to initialize with <any>undefined but that's impactful and weird
  
  
  • Some syntax for declaring that an initialization happens 'somewhere'
  
  
  • x!: number;
  
  
  • x: number!; (what would x: number!|string; mean?)
  
  
  • x: number = *;
  
  
  • Ambient decorator a.k.a. attribute (which we don't have yet...)
  
  
  • Workaround: Declare it in a co-interface instead
  
  
  • Doesn't allow for private/protected properties
  
  
  • Undiscoverable
  
  
  • Potential for a ! modifier on a declaration that says "Let me treat this as non-null when convenient"
  
  
  • We should allow optional property declarations in classes
  
  
  • and methods too (they must lack a body)
  
  
  • Currently a bug that we don't properly define the type of interface X { foo?(): void; }
  
  
  • Force classes to initialize and see how bad the breakage actually is
  
  
  • What about Abstract classes and properties
  
  
  • Note that we don't really know what an ambient abstract class constructor did
  
  
  • You must initialize all properties you declare
  
  
  • Assume that concrete properties are initialized by the base class
  
  
• # 8370 - this types for accessors
  
  
  
  • :+1:
  
  
• # 7271, #8168, #8316 - instanceof
  
  
  
  • Anders hates classes :wink:
  
  
  • What do we do with the only nominal thing in JavaScript?
  
  
  • Lots of actual code that only differentiates via prototype
  
  
  • We could do a local fix of instanceof (small + easy), or add nominal types back in some form (huge, been discussed before at length)
  
  
  • We should rewrite lib.d.ts to use classes now (we believe this to be safe)
  
  
  • :+1: treat class-declared types differently in instanceof
  
  
  • What about user type guards?
  
  
  • You could write x instanceof T instead of x is T in the predicate form
  
  
  • Or just say that is T is like instanceof T when T is a class type
  
  
  • (Extensive argument about nominal vs structural classes)
  
  

[JKillian]

👍 Thanks for writing these up - I'm sure they're an organizational help for the TS team, but they also are great for external TS users (like me) interested in where TS is going and the learning about the challenges in creating a language like TS.

[tinganho]

Some syntax for declaring that an initialization happens 'somewhere'
x!: number;
x: number!; (what would x: number!|string; mean?)
x: number = *;
Ambient decorator a.k.a. attribute (which we don't have yet...)

Maybe just declare a method as an initializer?

class A {
   a: number;
   init onMount() {
     a = 1;
   }
}

[basarat]

Extensive argument about nominal vs structural classes

FWIW flowlang has nominal classes. Everything else is structural :rose: