Skip to content

Design Meeting Notes, 3/6/2020 #37388

@DanielRosenwasser

Description

@DanielRosenwasser

Assignability Between {} and Unconstrained Type Parameters

#33570

  • When we added unknown, we also added a special case for unknown to be assignable to {} and Object.
  • A while back, we changed the default type parameter constraint of {} to unknown
  • This actually broke us as well!
    • A couple of places where we mixed and matched between {} and unknown.
  • Lots of failures, but mostly failures in the same package.
    • schema<T> where T really should've been updated to {}.
  • Does this break type parameters that explicitly extend {}?
    • No, there's no special casing for type parameters.
  • Is it pretty easy to fix?
    • Pretty consistent that people just have to change the constraints to only accept {} or object.
  • Not such a big fan of more breaks in the same release.
    • But the error messages are consistent around {}.
  • What about when you're not in strict mode?
    • There, unknown and {} are really the same thing.
    • Maybe that's why we kept the rule in the first place.
    • unknown is already assignable to {} outside of strictNullChecks, so this doesn't affect users there.
  • Who'd it break?
    • DefinitelyTyped
    • Office UI Fabric
      • Seems to be from DefinitelyTyped changes
  • Conclusion
    • Try to see whether we can at least give an actionable error on this change.
    • Let's hold it off for another release.

Update on Intersection Assignability with Optional Properties

#37195

  • Office UI Fabric got hit, gave them an update.

Checking Index Signatures In the Presence of Optional Properties

#27591

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions