Design Meeting Notes, 1/25/2019

[DanielRosenwasser]

Type parameters constrained to any

#29571

• We've had a test since forever, but TypeScript provides absolutely zero validation on usages of type parameter constrained to any.

const f = <T extends any>(arg: T) => {
    arg.whut; // no error!!!!!
}

• How often does this come up in practice?
  • When an error message says "this isn't assignable to this constraint", then you can imagine people just
• Depends on who gets impacted.
  • Check bigtestquery, other real world code.
• Seems like this could break behavior in the presence of what TypeScript falls back to in failed inferences.
  • Nope! We see if the inferred type is assignable to the constraint, and fall back to the constraint if not. Since we infer {} in the presence of no inferences and that's assignable to any, that's okay.

Apply contextual types from inferred return types

#29478

• Seems low risk - let's see if tests come back, and if so everything can go in for 3.3.

const contexts

#29510

Seems like there was some confusion on naming, but looks reasonable.

Improved simplification and restrictive instantiation of conditionals

#29437

• Doesn't T extend U always being true always imply that T subsumes T & U anyway?
  • Mostly yes! But in the presence of circularities.
• Right now this emulates what negated types would do.
• Do we want this in 3.3?
  • No, not the whole thing.
  • The restrictive instantiation is helpful.
• Rename some function as part of the PR 🤷‍♂️.

Unioning issues on thousands of object literals

#28707
#28727

• Dualing PRs
• Array literals with 30K distinct object literals
• This isn't 3.3 bound
  • It's been terrible since normalization
  • It's been slow since union types
  • Probably as bad when we used to fall back to {}.

Negated types

#29317

• Want to see how it affects control flow, and first want to look into index signature unification.

Index signatures

#26797

• Need to unify the idea of mapped types and index signatures.
• Maybe the idea here is that existing index signatures continue to work the way they do today, and any declarations of normal properties (i.e. using unions of literal types) don't have to apply.

  • How do you fall into this scenario?

    let foo: {
        [x: "a" | "b" | "c"]: boolean;
        [x: "c" | "d" | "e"]: number;
    };
    

• Could muse about a world where every property declaration "foo" with type T de-sugars to [x: "foo"]: T.
  • With that, negated types mean you can also ensure that certain properties can be excluded from needing to satisfy index signatures.

Contextually typed parameters with binding patterns

#28816

• Today, when we have to determine the type of a parameter, we ask
  1. Is there an annotation?
  2. Is there a contextual type?
  3. Is there an initializer?
  4. Can we build a type implied by the binding pattern?
• When you have a contextual type, but that contextual type is a type parameter in inference, then you run into an awkward loop.
  • What we arguably should do is say that contextual typing fixes the type parameter, and if the type parameter isn't constrained then you get inference to {}.
  • What we instead to is say there's no contextual type, try to infer from the binding pattern, and then infer to the type parameter.
• Turns out this has inconsistent experiences in the IDE.
• This is a breaking change under noImplicitAny, but we need to make a call

Different treatment of methods, functions expressions, and arrow functions

#29520

• In order to "validate" an instantiation of T
• The subtle difference is that 0-arity arrow functions are the only ones that are not contextually sensitive.
  • Sure it is!
  • Nope! It has no this parameter. The others do.
  • So the others are contextually sensitive and deferred.
• There's an expensive way to solve the problem.
  • We could clone the type mapper and not "fix" the type parameters during inference.
  • We can track whether the node itself contains this.
• Could potentially see if we could make it cheaper to clone mappers.
  • But couldn't that fix other parameters?
    • [[Potentially not - @weswigham @ahejlsberg, why?]]
• Possibly a design limitation, but may be interesting to tackle.
• A better pattern might just be to use negated types.

Invariant predicates

#26981
#27686

• Technically, user-defined type guards should be invariant.
• Unfortunately this breaks a bunch of things that appear reasonable in real world code.
• Error with {} to any because uses isIdenticalTo.