No widening in strict null checking mode #8944
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #8878 and supercedes #8907. The PR implements the following three changes:
[]
) have typenever[]
.null
andundefined
literals in strict null checking mode, this means that the concept of widening now exists only for backwards compatibility with classic type checking mode.null
andundefined
types when they originate innull
andundefined
literals used in expressions. We don't widennull
andundefined
when they're used as type annotations. This is essentially a bug fix.Since we expect
--strictNullChecks
to almost always be used in combination with--noImplicitAny
, it seems pointless to widen the type of empty array literals fromnever[]
toany[]
since we'll immediately report an implicitany
error following the widening. It seems better to preserve the more specificnever[]
type and require the programmer to add a type annotation if the array is actually going to be modified.So, where the experience previously was
the experience now becomes
Of course, when a type annotation is present there is no error:
By altogether avoiding widening we solve some long standing issues in #531 and #1436.