Repository navigation
Generic literal marker not obeyed for unknown and {} #32169
Description
TypeScript Version: 3.4 up to 3.6-dev20190628
Search Terms:
generic literal unknown
Code
This is expected:
function f<T>(x: T): T { return x; }
enum E { A, B }
let x = f(E.A); // x has type E, not E.AAccording to #24919 (comment) , you can get this to produce an E.A if you add an extends marker:
function f<T extends {}|null|undefined>(x: T): T { return x; }
enum E { A, B }
let x = f(E.A); // x now has type E.AExpected behavior:
I'd expect the same literal inference if you write these forms too:
function f<T extends unknown>(x: T): T { return x; }
function f<T extends {}>(x: T): T { return x; }Actual behavior:
It has the other behavior, as if you have no extends clause
Playground Link:
Related Issues:
Activity
ahejlsberg commentedon Jul 3, 2019
The exact rules we use for widening inference candidates are a bit more complex (see
getCovariantInferencefunction in the checker for implementation). We widen inferred literal types if:Primitive types are
string,number,bigint,boolean,symbol,void,undefined,null, and all literal and unique symbol types. The intent of the rules is to not widen when there is some indication in the constraint that a literal type is wanted. For example, a constraintnumberis a pretty clear indication that we want something that is a subtype ofnumber, i.e. a numeric literal type.I'm not sure I see a compelling reason to change these rules, in particular since it would likely break code that depends on the current behavior.
RyanCavanaugh commentedon Jul 3, 2019
Anders Hejlsberg (@ahejlsberg) why isn't e.g. widening to
numbergated on thenumberprimitive type (or a numeric literal type) appearing in the union?At a minimum, I would expect the non-values (
null,undefined,void) to not have any influence on literal widening.evmar commentedon Jul 3, 2019
The specific code this breaks for us is:
This function has the important property that it can be inserted around any expression to get the same result type out:
However, you cannot pass
unknownto this function as written, and changing the param toT extends unknownor plainTmeans it now widens.(You might wonder why there's any code that ever assert()s on an unknown, because the return type isn't useful. But it still is useful because it throws on null.)
This came up in particular in TS3.5, because we are seeing a lot more code that ends up passing around unknowns, due to the default constraint change (#30637).
ahejlsberg commentedon Jul 4, 2019
So, first of all, in the original example
the reason for the widened type is that
xis a mutable location. If you declare withconstwe don't widen. The reason we don't widen is becauseToccurs at top-level in the return type, as per the rules above.However, when the example is changed to
we start widening because we don't consider the occurrence of
Tin the return type to be top-level. From #10676, the original PR for literal typesWe never updated this rule to account for conditional types. I think we should augment the definition to
That should fix the specific code that is breaking (because the type parameter constraint doesn't even matter then).
ahejlsberg commentedon Jul 4, 2019
In general, if we're going to keep literal types we should keep them for all types, not just some types. And if the constraint is
numberit doesn't really matter if we keep literal strings because they'll fail the constraint check anyways.You could argue that we shouldn't consider
nullorundefinedin the constraint a reason to keep literal types (i.e. to not widen), but I'm not super eager to mess with these rules and have something break because of it, and it is unrelated to the real fix for the problem in this issue.ahejlsberg commentedon Jul 5, 2019
Changing this to be a bug, the bug being that the check for top-level occurrences of a type parameter should be augmented to handle conditional types as I describe above.