Allow partial unions for indexed type access

[nomcopter]

Solves #21975 and #14366 by allowing partial union types for indexed type access as opposed to creating a null assertion type operator.
@mhegazy @DanielRosenwasser

Fixes #21975
Fixes #14366
Related #16108

[msftclas]

All CLA requirements met.

[RyanCavanaugh]

@ahejlsberg take a look?

[ahejlsberg]

Looks good, but needs the suggested change. Also, please add a test to ensure the expected error is reported.

[ahejlsberg]

This is a too permissive. For example, it will allow the following to compile with no error:

interface Foo {
    bar: { baz: string } | { qux: number }
}

function f(x: Foo) {
    return x['bar']['baz'];  // Should be an error
}

It's pretty easy to fix through:

const prop = getPropertyOfType(objectType, propName, !accessExpression);

This will allow partial unions only when the indexed access doesn't originate in an expression.

[nomcopter]

Ah good catch. Fixed! Thanks for the review @ahejlsberg

[mhegazy]

@ahejlsberg any more comments?

[weswigham]

We actually have a NonNullable operator now, though.

[mhegazy]

We actually have a NonNullable operator now, though.

u mean generic type? the idea is not to force users to write the type reference if all what they want is to get to the type of the property.

[weswigham]

I don't think it's a good idea to implicitly filter the union given to only the applicable elements, since now conditional types exist and allow users to explicitly perform that filtering if need be themselves.

[weswigham]

Like, index has the nice property that that's the inverse of a mapped type right now, this breaks that - a mapped type will never produce multiple "possible" object types.

[weswigham]

I'm going to insist that this does not feel like a primitive operation anymore when you do this. You can easily write an Index<T, U> now that has this only-chooses-applicable-members behavior if you need to, but the reverse isn't true. If we take this, there's no way to gain back the type safety.

For posterity: type Index<T, U extends string> = T extends {[K in U]: any} ? T[U] : never

Note how I had to use our current index operator in the definition. If index becomes loose by default, writing a strict version becomes impossible because there's no way to write a type that can trigger the same errors...

[nomcopter]

Sorry I don't entirely follow. Can conditional types be used to do the following?

interface Foo {
    bar: {
        baz: string;
    } | {
        qux: number;
    }
}

type ShouldBeString = Foo['bar']['baz'];

What favorable errors would be impossible after this change? Could you give an example?

[mhegazy]

OK, I have added this issue to the agenda of the next design meeting; let's see if we can reach consensuses about this.

[mhegazy]

Discussed this again in #22445. Conclusion, with NonNullable available now with conditional types, the original scenario should be unblocked, no reason to add new rules.