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
Code
More a suggestion than a bug. I found out that there are a few situations where enabling strictNullChecks results in unnecessary complexity in the code. For example :
if ( myArray.length > 0 ) {
let o: Object = myArray.pop();
o.method();
}
Expected behavior:
should compile
Actual behavior:
requires a Object | undefined type and an additional safety test
if ( myArray.length > 0) {
let o: Object | undefined = myArray.pop();
if (o) {
o.method();
}
}
Though I would still like to know if there is plan when this will work automatically.
there is no plans to change how it works. This operator is an escape hatch to force the compiler to forget about the null and undefined in the type if the value is set in call back or inner function that the control flow analysis does not have access. it is the user saying "trust me, i have initialized this already".
if TS will know that pop does not return undefined if length > 0
That requires all sorts of codependent relationship of properties and a system for expressing them. Just because an Array has a property that is .length and and if that .length is a positive integer, then certain methods of Array will return their type, versus undefined, that doesn't mean that is true of other objects that have length. Also, Map and Set have the property .size but no .length, so you would have to write a rule for that as well and express all of that in the return typings.
Do you have a proposal for how one could express that? Even if there was a syntax like that, really would it be worth the effort?
Maybe something crazy like:
interfaceArray<T>{pop(): this.length>0 ? T : undefined;}
But CFA would have to keep a lot more in mind at every code point, just in case it was needed for evaluation. It would also broaden significantly the complexity of the state model I assume as well, because it wouldn't just be a handful of types tracked, but essentially an unbounded level of literal types for evaluation.
Activity
jeffreymorlan commentedon Sep 23, 2016
The
lengthcheck is unnecessary.popon an empty array returns undefined and leaves the array empty:Bobris commentedon Sep 23, 2016
Workaround I am using is to help TS with bang:
jice-nospam commentedon Sep 23, 2016
Boris Letocha (@Bobris) Thanks, I wasn't aware of the Non-null assertion operator. I should have read the documentation!
Bobris commentedon Sep 23, 2016
For random readers: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#non-null-assertion-operator
Though I would still like to know if there is plan when this will work automatically.
mhegazy commentedon Sep 23, 2016
there is no plans to change how it works. This operator is an escape hatch to force the compiler to forget about the
nullandundefinedin the type if the value is set in call back or inner function that the control flow analysis does not have access. it is the user saying "trust me, i have initialized this already".Bobris commentedon Sep 23, 2016
Mohamed Hegazy (@mhegazy) I meant original question, if TS will know that pop does not return undefined if length > 0.
mhegazy commentedon Sep 23, 2016
oh.. i see. that is gonna be tough.
kitsonk commentedon Sep 24, 2016
That requires all sorts of codependent relationship of properties and a system for expressing them. Just because an Array has a property that is
.lengthand and if that.lengthis a positive integer, then certain methods of Array will return their type, versusundefined, that doesn't mean that is true of other objects that havelength. Also,MapandSethave the property.sizebut no.length, so you would have to write a rule for that as well and express all of that in the return typings.Do you have a proposal for how one could express that? Even if there was a syntax like that, really would it be worth the effort?
Maybe something crazy like:
But CFA would have to keep a lot more in mind at every code point, just in case it was needed for evaluation. It would also broaden significantly the complexity of the state model I assume as well, because it wouldn't just be a handful of types tracked, but essentially an unbounded level of literal types for evaluation.