You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we have spreads with optional properties, we don't correctly mix in undefined.
declareletr: {[key: string]: number};declareletfromAnnotation: {x?: number};r={ ...fromAnnotation};// Error: Type 'undefined' is not assignable to type 'number'.letfromExpression={ ...!!true ? {x: 3} : {}};r={ ...fromExpression};// Ok
Also discussed allowing properties with undefined to be assignable to an index signature.
Likely can't truly fix index signatures to always implicitly produce undefined because of arrays.
We could do this just for string index signatures.
With the string index signature behavior permitting undefined properties, how does this extend to our "generalized key types"?
Would imagine that it does extend correctly.
What about delete?
What's the mechanism for this? Some higher-order thing?
No, strip out undefined from the property before the check.
Is it weird to make an exception for numeric index signatures?
Probably doesn't matter.
Totally matters
consttuple=[undefined,2,3]asconst;vararr: number[]=tuple;// make sure this still errors
Is there a way to track whether these were optional to begin with? And only do the check then?
A more limited change, and you can't take back the behavior as easily if you always allow undefined.
declareletfromAnnotation2: {x: number|undefined};// Error: Type 'undefined' is not assignable to type 'number'.declareletr: {[key: string]: number}={ ...fromAnnotation2};
Conclusion: try this with just optional properties.
The magic happens in indexTypesRelatedTo with eachPropertyRelatedTo.
Numeric index signatures are supposed to map a subset of string properties.
This breaks transitivity.
Wait, no, it's fine.
Hearkens back to the "dense vs. sparse" conversation in the first topic.
Having no numeric properties means that you should be compatible technically!
In line with the original change.
What breaks?
Test based on Mithril
Office UI Fabric
RxJS (but in a good way)
Anecdote: we have a tendency to say "oh my gosh, what's a user supposed to do?", but when outside the team, we would take the time to fix correctness issues and we'd be better off doing it.
Historically, with issues like this, how helpful have we found the release notes to be helpful?
Mixed bag, but it does help a lot of people.
Original scenario is compelling; what about an alternative approach.
Implemented object type a while back - might want to create a function type?
Opposite use-case, doesn't help here.
Conclusion: evaluate what the fixes feel like on the codebase.
The text was updated successfully, but these errors were encountered:
Infer Template Literal Types from Template Expressions
#41891
string
.const
preserves the literal-ness, whilelet
enforces a widening`hello${string}world`
from`hello${foo}world`
, does that mean you're expecting at least one character in the middle?`hello${T}${U}world`
whereT
andU
both extendstring
.string
.Optional Property Checking Against Index Signatures
#41418
#41505
When we have spreads with optional properties, we don't correctly mix in
undefined
.Also discussed allowing properties with
undefined
to be assignable to an index signature.undefined
because of arrays.With the string index signature behavior permitting
undefined
properties, how does this extend to our "generalized key types"?What about
delete
?What's the mechanism for this? Some higher-order thing?
undefined
from the property before the check.Is it weird to make an exception for numeric index signatures?
Probably doesn't matter.
Totally matters
Is there a way to track whether these were optional to begin with? And only do the check then?
A more limited change, and you can't take back the behavior as easily if you always allow
undefined
.Conclusion: try this with just optional properties.
indexTypesRelatedTo
witheachPropertyRelatedTo
.Option to Use unknown in
try
/catch
Variable Types#41013
strict
, getting better checks, right?noImplicitAny
, is that an error today?strict
mode flag.noImplicitAny
.strict
is being open to being broken as soon as we get better.: any
quick fix.strict
Remove Special
any
Assignability Exception from Numeric Index Signatures#41660
object
type a while back - might want to create afunction
type?The text was updated successfully, but these errors were encountered: