Narrowing lost in polymorphic function application

[sledorze]

TypeScript Version: 3.1.0-dev.20180921 (next)

typescript@3.1.0-dev.20180914 <- works as expected.
typescript@3.1.0-dev.20180915 <- problem started to appear at that very version.

Search Terms:

generic inference regression

type XY = 'x' | 'y'
const x: XY = 'x'
interface Opt<T> {
  v: T
}
const foo = <T>(v: T): Opt<T> => ({ v })
const foox = foo(x) // Opt<string> instead of Opt<XY> (Regression)

const bar = <T>(v: T): Opt<typeof v> => ({ v })
const barx = bar(x) // Opt<string> instead of Opt<XY> (Regression)

const baz = <T>(v: T): T => v
const bazx = baz(x) // 'x' (OK)

Expected behavior:

Expected union type to be preserved

Actual behavior:

Union type is expanded to string

Playground Link:

This Playground Link demonstrate the CORRECT Behaviour (because previous typescript version is used in the playground)
http://www.typescriptlang.org/play/#src=type%20XY%20%3D%20'x'%20%7C%20'y'%0D%0Aconst%20x%3A%20XY%20%3D%20'x'%0D%0Ainterface%20Opt%3CT%3E%20%7B%0D%0A%20%20v%3A%20T%0D%0A%7D%0D%0Aconst%20foo%20%3D%20%3CT%3E(v%3A%20T)%3A%20Opt%3CT%3E%20%3D%3E%20(%7B%20v%20%7D)%0D%0Aconst%20foox%20%3D%20foo(x)%20%2F%2F%20Opt%3Cstring%3E%20instead%20of%20Opt%3CXY%3E%20(Regression)%0D%0A%0D%0Aconst%20bar%20%3D%20%3CT%3E(v%3A%20T)%3A%20Opt%3Ctypeof%20v%3E%20%3D%3E%20(%7B%20v%20%7D)%0D%0Aconst%20barx%20%3D%20bar(x)%20%2F%2F%20Opt%3Cstring%3E%20instead%20of%20Opt%3CXY%3E%20(Regression)%0D%0A%0D%0Aconst%20baz%20%3D%20%3CT%3E(v%3A%20T)%3A%20T%20%3D%3E%20v%0D%0Aconst%20bazx%20%3D%20baz(x)%20%2F%2F%20'x'%20(OK)%0D%0A

Related Issues:

I think this bug is very recent; I've not found anything relevant.

[ahejlsberg]

A smaller repro:

type XY = 'x' | 'y';
const x: XY = 'x';
let x2 = x;  // Has type string

We definitely shouldn't be widening the type of x2 to string.

[ahejlsberg]

@weswigham @RyanCavanaugh We should look at this one right away.

[ahejlsberg]

Timing seems to indicate this is an effect of #27042.

[weswigham]

I can point exactly to what causes this, because (at least for booleans, which were the motivator) it was intentional. In

type XY = 'x' | 'y';
const x: XY = 'x';
let x2 = x;  // Has type string

x's declared type is narrowed by it's assigned type of a fresh 'x', resulting in a fresh 'x' (since the narrowing type was fresh) which then widens on assignment to let. Take the same example for boolean:

const x: boolean = true;
let x2 = x;  // Has type boolean

Without this rule, x2 would just be true. So do we want to remove the freshness-carries-through-narrowing change for all types? Keep it for just boolean?

[ahejlsberg]

@weswigham See my comment here.

[ahejlsberg]

Repeating my comment in #27042, the intuitive rule was always that once you add a type annotation to let, const or var declaration, values read from that variable are not fresh. But now they are unless the annotated type is a unit type.

const x1: 'x' = 'x';
let z1 = x1;  // 'x'

const x2: 'x' | 'y' = 'x';
let z2 = x2;  // Was 'x', now string

I find it hard to construct a rationale for that.

[weswigham]

Hm, but the annotation actually wasn't why that was the case, strictly speaking. It was simply because the types we were narrowing by weren't fresh. If by chance you narrowed by a union of fresh types (because, eg, the union type is built up from conditional expressions) it would behave exactly like this already, even if it were annotated!

[weswigham]

The reason I added the change was for consistency, because a union of fresh types like that is built for booleans all the time (while it's more rare for other literals) and consistiency between the declared and constructed forms of the types seemed desirable.

[ahejlsberg]

Hm, but the annotation actually wasn't why that was the case, strictly speaking.

As I said above, the core intuition was always that once a type annotation was present in the path that a value traveled, the value would loose its freshness. That's broken now in a way that I don't think I can explain.

I think we need to stick with the old rules. If they don't work for fresh booleans then maybe we don't need fresh booleans.

[weswigham]

I think we need to stick with the old rules. If they don't work for fresh booleans then maybe we don't need fresh booleans.

It's more like the old rules are very unintuitive for booleans which previously widened everywhere.

As I said above, the core intuition was always that once a type annotation was present in the path that a value traveled, the value would loose its freshness. That's broken now in a way that I don't think I can explain.

We could choose preserve that intuition with a different change (ie, by actually explicitly having a rule governing it) - by explicitly stripping the freshness measured from an initializer of a statement with a declared type.