Closed
Description
Remove undefined
from Optional Properties When Inferring to Index Signatutres
declare function foo<T>(obj: { [x: string]: T }): T;
declare const x1: { a: string, b: number };
declare const x2: { a: string, b: number | undefined };
declare const x3: { a: string, b?: number };
declare const x4: { a: string, b?: number | undefined };
let a1 = foo(x1); // string | number
let a2 = foo(x2); // string | number | undefined
let a3 = foo(x3); // string | number
let a4 = foo(x4); // string | number
- First two are uncontroversial.
- Second two...we effectively see those are the same.
- Intent of last one isn't clear.
- Need
missing
. - Half of the world's
undefined
ismissing
and half is stillundefined
.
- Probably fine to skew towards not including
undefined.
- Reminds of "safe
any
" missing
<undefined
- ...
void
<undefined
? - Can you use
void
?- Sadly no.
- ...
- Hard to guess how breaky the world would be.
- Have to just see.
- The current "optimistic" strategy in the PR seems good. People who badly want to deal with
undefined
in these cases may just want--noUncheckedIndexedAccess
.
Exclude enum/number compatibility rule from comparable relation
- Last design meeting notes seemed inconclusive.
- Seems like convo in issue is positive - merge.
Efficiency in Narrowing Generics
- Need to sync up on rules.
- Makes no sense that a
T extends unknown
can be checked against=== "foo"
, but a bareT
with no constraint is allowed. - If two type parameters are distinct, and neither references the other in a constraint, then they shouldn't be comparable.
- Makes no sense that a
- It seems questionable that you even want an error there. Can someone defend it?
- Can always argue that anything is fair game for
===
,.includes
, etc. But then you allow a big class of mistakes of relating unrelated entities. - Well we definitely like the
number <-/-> string
errors, those aren't as questionable. - But most generics have no constraint, so if you allowed the comparison, you could accidentally allow comparisons against the wrong thing.
- Can always argue that anything is fair game for
- Is comparability what we use for uncalled functions?
- No.
- Okay, what about creating intersections with generics?
- We end up with a huge number of types in certain codebases (compilers with unions?)
- For primitives, we can do this fast. For object types, we're very bad about it.
- What about the discriminant checks we recently did?
- Could potentially do that?