Repository navigation
Why is type assignability for any and enum so permissive? #22464
Description
Keywords: any, null, undefined, enum, assign, assignable, assignability, permissive, strict
From the spec:
S is assignable to a type T, and T is assignable from S, if S has no excess properties with respect to T (3.11.5) and one of the following is true:
- S and T are identical types.
- S or T is the Any type.
- S is the Undefined type.
- S is the Null type and T is not the Undefined type.
- S or T is an enum type and the other is the primitive type Number.
Why is:
- S assignable to T, if S is
anyand T is notany? - S assignable to T, if S is a
numberand T is an enum? Because enum <: number, T should be assignable to S, but why is the reverse true? And why is this not the case for string enums? S assignable to T, if S is(this was a Playground bug where strictNullChecks wasn't actually applied)undefined?S assignable to T, if S isnulland T is notundefined?
Have you guys considered a flag to opt out of some or all of these behaviors? Or are there real uses cases for them besides interop with untyped JS (or TS in non-strict mode)? I read through the spec and searched issues, but had trouble finding a discussion of why TS made these design decisions.
Activity
[-]Why is type assignability with null/undefined so permissive?[/-][+]Why is type assignability for any and enum so permissive?[/+]RyanCavanaugh commentedon Mar 11, 2018
We think
const v: T = <any>(expr);should not be an error regardless ofTor the type ofexpr. There is always a more-safe type assertion available; someone changing an expression's type toanyshould be a 100% Get-out-of-jail-free card."But not all
anys come from casts!" you say... Right.noImplicitAnyis designed to preventanyfrom appearing in places where you (or someone else) didn't say something wasanyvia explicitly writing that spelling of the type in some place or another.There's still the issue of
anyappearing in lib.d.ts definitions. I think there's a market for a stricter lib.d.ts that putsunknownin place of allanys, but intrinsically changing the definition ofanyto something else isn't something we think is a productive route.Because there's a bit of a paradox presented by the bitwise operators. See #17734, #21546, #11559, #15591 and other issues on this; it's been brought up a few times.
Most weeks we review about a dozen suggestions for new flags, and we've been doing that for about five years now, so... yes 😉
bcherny commentedon Mar 11, 2018
This makes complete sense. Thanks for the quick and detailed response :)