Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inferred index types on type parameters don't propagate through NonNullable<T> #26942

Closed
SLaks opened this issue Sep 6, 2018 · 1 comment
Closed
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@SLaks
Copy link

SLaks commented Sep 6, 2018

TypeScript Version: 3.0.1-insiders.20180726

Search Terms: I don't even

Code

class Endpoint<T = {}> { // This actually has 2+ parameters
    t!: T;
}

class ConfigReader<TEndpoint extends Endpoint> {
    constructor(readonly endpoint: TEndpoint) { }

    getValue(): NonNullable<TEndpoint['t']> {
        return this.endpoint.t;
    }
}

Expected behavior:

No compiler error

Actual behavior:

Type '{}' is not assignable to type 'NonNullable<TEndpoint["t"]>'.

Playground Link:
https://www.typescriptlang.org/play/index.html#src=class%20Endpoint%3CT%20%3D%20%7B%7D%3E%20%7B%20%2F%2F%20This%20actually%20has%202%2B%20parameters%0D%0A%20%20%20%20t!%3A%20T%3B%0D%0A%7D%0D%0A%0D%0Aclass%20ConfigReader%3CTEndpoint%20extends%20Endpoint%3E%20%7B%0D%0A%20%20%20%20constructor(readonly%20endpoint%3A%20TEndpoint)%20%7B%20%7D%0D%0A%0D%0A%20%20%20%20getValue()%3A%20NonNullable%3CTEndpoint%5B't'%5D%3E%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20this.endpoint.t%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A

Motivation:

In my actual code, ConfigReader has 4 type parameters, each of which is a further config class with even more nested parameters. I'm trying to avoid putting ~15 type parameters on ConfigReader by bundling them in this fashion, accepting a single type parameter for each top-level thing and accessing their nested type parameters via [] notation.

This works perfectly (so far), except for this issue.

@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Sep 20, 2018
@RyanCavanaugh
Copy link
Member

We currently don't have a way to validate that the control flow of any particular function satisfies a conditional type (which NonNullable is) - a type assertion is needed here to indicate that you've correctly handled the case where this.endpoint.t is null/undefined

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

2 participants