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
This ties into an ongoing discussion about what we think about the use/addition of nominal types in our type system. There is a long list of issues related to nominal types.
It looks like this feature is actually working as designed, though the behavior is admittedly a bit counter-intuitive at first glance. Based on the recent addition of the comparability relation (issue #5517), specifically here, x isn't comparable to '0' because '0' is a numeric literal, and thus a subtype of 'number'. Here are two workarounds (inspired by your comment here :) ):
type BrandedNum = number & { __numberBrand: any };
declare var x : BrandedNum;
x > 0; // error: 0 is of numeric literal '0', a subtype of number
x > <number>0; // okay
x > <BrandedNum>0; // okay, in my opinion the clearest
In fact, this should be a general solution for dealing with "nominal typing" via brands: upcasting the other argument to a comparison operation to that of the two types' common ancestor will make the comparison pass our type check.
aozgaa
added
By Design
Deprecated - use "Working as Intended" or "Design Limitation" instead
Design Limitation
Constraints of the existing architecture prevent this from being fixed
labels
Oct 19, 2016
The text was updated successfully, but these errors were encountered: