Skip to content

Investigate (possibly contextual) truthiness narrowing of type parametersΒ #49005

Closed
@DanielRosenwasser

Description

@DanielRosenwasser

In the TypeScript 4.7 timeframe, we introduced stricter behavior in strictNullChecks around unconstrained type parameters and empty/weak object types in #48366.

function foo<T>(x: T) {
    // should be an error because T could be null/undefined
    let obj: {} = x;
}

However, we but had to revert it back before our release candidate in #48923 because it was so invasive, and it really didn't catch a lot of bugs.

Still, we found a few examples of false-positive cases where users properly narrowed generics, but were encountering the error (#48468).

function foo<T>(x: T) {
    if (!x) return;

    // Should work.
    let obj: {} = x;
}

We wondered if we could provide some degree of narrowing. One experiment was in #48576, where we would only do narrowing in certain contexts on unconstrained type parameters to avoid invasive changes and narrowing time, but it is fairly specific to unconstrained type parameters, and provides poor error messages.

Another idea that @ahejlsberg and @RyanCavanaugh had was to leverage intersection types with {} to narrow truthiness checks. At the moment, the ideas involve being more aggressive in subtype/supertype reduction with {}, so this may introduce surprising changes; however, if we find the results are good, maybe we can take another swing at #48366 down the road.

Metadata

Metadata

Assignees

Labels

Experimentation NeededSomeone needs to try this out to see what happensFix AvailableA PR has been opened for this issueIn DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions