Design Meeting Notes, 4/15/2019

[DanielRosenwasser]

The non-inferrable type

#30856

• In resolveCallExpression, there's a big ol' comment with some context ("When a call to a generic function").

• We have this thing called the anyFunctionType, which signals that we are trying to defer inferring from contextually-sensitive function expressions.

• We have situations like the following:

  outer(..., ..., inner(x => ...), ...);

  • inner could have a type like <T>(x: T) => T
  • We need to defer the call to inner for the same reason, but we need some sort of marker type like anyFunctionType that isn't technically a function type.
  • It's extremely subtle, but there were issues in Ramda where this occurred.
  • @weswigham

• Causes some breaks other breaks on DT.

• On the whole, this is a specialization of work where we were previously using a silentNeverType.

Excess property checking when relating to intersections and unions

#30853

• Many long-standing issues around excess property checking.
• In principle, an object with more properties than is expected is "fine" - basic "width" subtyping.
• But usually it's an error when people pass object literals - so we added excess property checks for options bags.
  • Aside: also did overlap checks for weak types for similar reasons.
• Problem is, we do this on the top-level of relationship checks, but don't do it on nested properties of intersection types
• Gets more "interesting" when you do excess properties on unions.
  • If assigning an { a, b, c, d } object literal to { a, b } | { c, d }, it's plausible
  • Probably not an { a, b, c, d, e } though.
  • @weswigham, why again? Something about discriminant types.
• Opened about 18 PRs in DefinitelyTyped for questionable tests, entirely missing declarations, or completely wrong declarations.
• Error messages got a lot shorter too.
• Weirdly, we found errors on code for SomeOptions | object.
  • It's a nonsense type...but is it wrong to report errors on it?
  • It legitimately caught bad stuff being passed!
• This is a breaking change. ☹
  • None of the changes should feel "debatable" given how 3.4 went.
• We need to make a call on SomeOptions | object being excess-property checked the same as SomeOptions.
  • It really does seem reasonable.
• Assigning { b, c, d } to { a, b } | { b, c }.
  • Only works if you're assignable to the union without excess property checking anyway.
  • We could expand excess property checking to go deeper in the union - but this is future work.
• Resolution: pull it in.

Make the Omit type stricter

#30825

• Would it be more irritating to use Omit if it has a constraint?
  • Adding a constraint would force users to add an explicit constraint where they use it.
• DefinitelyTyped is mixed in Omit that is constrained and unconstrained - not entirely clear whether it's just one or the other.
  • https://github.com/DefinitelyTyped/DefinitelyTyped/search?p=6&q=%22type+Omit%22&unscoped_q=%22type+Omit%22
• Languages like Rust propagate the constraints outwards.
  • Might be weird that a T with no constraint gains an implicit constraint.
  • But maybe not that weird?
• Resolution: not worth breaking half the usages of Omit in the wild.

keyof on unknown and never

#30753

• Today:
  • keyof unknown is never.
  • keyof never is also never.
• But keyof is contravariant in its bounds with respect to its operand.
  • keyof on never should be unknown
  • But can only really be PropertyKey (a.k.a. keyof any).
• So change is that keyof never is now keyof any.
• Aside: funny that keyof keyof never isn't never.
• Resolution: Seems reasonable.