Repository navigation
make the strict equality comparison operator a typeguard for string literal types #7447
Description
Activity
👍
I had a draft of this kind of guard working in #6062, and Anders Hejlsberg (@ahejlsberg) has added some form of this guard to #7140 for at least
nullandundefinedvalue types, for reference.+1
As a note, I don't think we could narrow from
stringbecause that would cause breaking changes.Reacted by Herrington DarkholmeThe problem here is this breaking change (and arguably undesirable behavior):
const hey: 'hey' = 'hey'; const value = Math.random() > 0.5 ? 'hey' : 'nay'; if (value === hey) { // here expected value to be of type 'hey' (we just asserted it), actual string let q = value; if (...) { q = 'never mind'; // error, can't assign "never mind" to "hey" } }
The use case for changing this isn't super compelling since you have the right operand
heyof===available to you for use inside theifbody already with the type you want already, so narrowing the left operand doesn't seem super useful. Obviously one or the other may have been computed and not stored, but it's still probably not worth taking a breaking change for unless we can see how it's going to make some other piece of code a lot better.mind me asking, can
qbestring | 'hey'thank to flow analysis?
'hey'in one context andstringin another?const hey: 'hey' = 'hey'; const value = Math.random() > 0.5 ? 'hey' : 'nay'; if (value === hey) { let q = value; // originaly string but then asserted but then might be reassigned if (...) { q = 'never mind'; // no pasa nada } }
How is this breaking change different from other breaking changes related to narrowing? They all can cause that narrowing causes that the type of a variable is too specific. In this case it's very easy to solve it, just add
: string.This was just suggested again in #9314. It is related to Ivo Gabe de Wolff (@ivogabe)'s suggestion here and I'm starting to think it has some merit. Specifically, for any type guard on a reference
x.y, we would also narrowxitself based on the narrowed type ofx.y. It effectively generalizes discriminant type guards to work over the entire set of existing type guards.To be clear, my concerns about narrowing were about narrowing from
string. If you had a union of string types, I'd argue that you are probably using the strings as tags and want the narrowing behavior for things like overloads and ensuring exhaustiveness. On the other hand, narrowing fromstringmore likely to break transitive assignments, and there is no such thing as exhaustive checking of allstrings.Agreed, we only want to narrow from unions of string literal types, not from the
stringtype itself.The original suggestion in this issue along with a number of other features is now implemented by #9407.
- locked and limited conversation to collaborators
on Jun 19, 2018
1.9.0-dev.20160217
Code