Repository navigation
Arrow functions cannot be used as user-defined type guards #5951
Description
User defined type guards work perfectly well for classic function statements, as in the release notes:
interface Animal {name: string; }
interface Cat extends Animal { meow(); }
function isCat(a: Animal): a is Cat {
return a.name === 'kitty';
}However, it appears that the arrow function equivalent isn't acceptable:
// Doesn't compile
var isReallyCat: (a: Animal) => a is Cat = (cat) => cat.name === 'kitty';This gives "Type '(cat: Animal) => boolean' is not assignable to type '(a: Animal) => a is Cat'. Signature '(cat: Animal): boolean' must have a type predicate". I'm not clear how I would give that arrow function a 'type predicate', beyond what's already included here.
Is there a good reason for this? I can't seem to find it documented anywhere.
Activity
Arnavion commentedon Dec 6, 2015
Using a type assertion instead of type annotation does work
so I imagine it's just an oversight rather than deliberate.
DanielRosenwasser commentedon Dec 6, 2015
The issue is that you don't want a
boolean-returning function to be assignable to a type-guard.or just
We could contextually type the return type to be a type predicate when appropriate, but I don't know if it'd really be worth it, and we usually never touch return types when performing contextual typing.
Arnavion commentedon Dec 6, 2015
Why not? Nothing prevents me from implementing a
x is Foofunction withMath.random()either.DanielRosenwasser commentedon Dec 6, 2015
Sure, but you have to intentionally opt in to that, and if you're totally sure you want to sabotage your users' experiences, more power to you. We're trying to avoid people from accidentally assigning an arbitrary function to a type predicate.