Design Meeting Notes, 2/12/2016

[RyanCavanaugh]

• Implicit Index Signatures Implicit index signatures #7029
  • issue Why does { foo: T } not satisfy { [key:string]: T }? #6041 and many others logged in the past
  • Longstanding pain point / confusion source
    • e.g. see upvotes on http://stackoverflow.com/questions/22077023/why-cant-i-indirectly-return-an-object-literal-to-satisfy-an-index-signature-re
  • Bad solution you might think of: Infer this all the time
    • Very bad -- passing string to Map<T> infers insane type for T, for example
  • Now infer index signatures during assignability in certain cases
    • Allowed for types inferred from object literals and object type literals, which do not have call/construct signatures
      • Object type literals because .d.ts files
  • Now we don't need to contextually type in index signatures
    • Error message quality improves
    • We can identify the violating member of an object type
  • Q: What's the difference between an interface and an object literal type?
    • Interface types are always explicit
    • No one is complaining about that (yet?)
    • Main problem seems to be in object literals
  • Concern: Switching from type alias to interface is going to have behavioral differences
    • We could include interfaces, but it's a trade-off with detecting errors
  • Q: What are the other differences between object literal types and interfaces?
    • You can inherit from an interface
    • Display (name vs anonymous type)
    • Concern: This breaks an existing symmetry
  • Could we just infer a string indexer for all object literals?
    • This would cause a lot of error noise
    • Plus type allocation
  • Q: What happens to type queries of these object literals? Are they still object literal types?
    • Yes, same type
  • Concern: Symmetry of declaration file vs implementation file, vs symmetry of object type literal vs interface type
    • e.g. What if we wrote the index signature into the .d.ts file during generation?
  • Note that this index signature isn't actually present -- indexing the object by a string is still an implicit any
  • What about only inferring the index signature when all properties have the same type?
    • Not useful, consider { x: HTMLSpanElement, y: HTMLDivElement }
  • 👍
• Constructor Visibility Constructor Visibility #6885
  • Issue Allow visibility on constructors #4174
  • What are the exact assignability / visibility rules?
    • As written
  • Add testcases for class expressions in the PR
  • TODO: Log issue that class expressions inside classes can refer to their enclosing class's privates / protecteds
  • It should be legal to extend a private constructor from within a class expression inside that same class
  • Otherwise good to go
• Type acquisition
  • TL;DR version
    1. We can't fix this until people write their .d.ts files as true modules
    2. But we have to because people haven't
    3. But we can't
    4. But we have to
    5. But we can't
    6. But we have to
  • We need to solve the problem of why people are writing .d.ts file as globally-declared external modules
    • Because global type augmentation was impossible
    • Because augmentation of other types was hard
    • Because UMD pattern
    • Because you don't want 200 .d.ts files if you have 200 modules
      • Can we fake this as long as there are no global declarations?
  • Consequentialism vs Platonic ideals
  • Is versioning conflict a real thing?
    • Badness of problem vs commonness of occurence
    • When will this happen?

[saschanaz]

Out of curiousity, what does 'type acqusition' mean here?

[kitsonk]

@saschanaz I believe it refers to how ambient types are acquired, in hopes of trying to make it manageable to resolve the "diamond" problem of type definitions at the moment, Lib A uses NodeJS 0.12 and Lib B uses NodeJS 4.1 and then you include both in your project and "BOOM!".

@RyanCavanaugh in regards to the 200 files problem, we have started trying to get Dojo 1 typings into some sort of shape, we have roughly aligned them to packages, but actually breaking them out to individual .d.ts files with, I would assume dependent references, would be a bit crazy for us, which I suspect

Is there any way the TypeScript team, in their mind, would make it easier to organise a large type library like that?

[saschanaz]

@kitsonk I see, thanks 👍

[mhegazy]

Is there any way the TypeScript team, in their mind, would make it easier to organise a large type library like that?

we are trying to come up with some guidance here. but at the moment, we do not have much. so far ideas are around using modules and avoiding global pollution, creating a different definition file for modules, and one for script, and making it easy to share definitions between them.

[yortus]

We need to solve the problem of why people are writing .d.ts file as globally-declared external modules

At least in some cases, newer approaches (eg module augmentation) don't work, leaving global ambients as the only working alternative. See #7015.