Use `instanceof` instead of `is` in type guard function syntax

[mihailik]

The type guard syntax introduces a new keyword is
#1007 Support user-defined type guard functions
#3262 Custom type guard function

(the latter was implemented by @tinganho and merged in master recently with 6e69a9e )

The syntax is quite elegant and clean, but can be further improved. It's generally a good rule to try and avoid introducing new keywords. Especially when a very similar one already exists in the language.

I suggest we use the existing instanceof instead. The meaning fits, and it's very familiar to a lay JS folk.

In simple words, to a person with JS background, but a limited TS one (1) leaves more to guess than (2):

function isApple(p1: any): p1 is Apple { }    // (1)   <-- man... let me remember what's the difference...

function isApple(p1: any): p1 instanceof Apple { }    // (2)   <-- hello, I know you!

I do agree that for the C# audience they both are fine. But similarly to bool/boolean swap of the early TS versions, preferring JS over C# is the right thing.

[JsonFreeman]

I'm not sure the is keyword is actually based on C#. That was not my interpretation.

I will say instanceOf has a prototype connotation, whereas is is intended to describe our structural type system. In that light, I actually think instanceOf could be misleading. The user might think that they should only use it when the function implementation does an instanceOf check.

[RyanCavanaugh]

Experience with re-using an existing value-position keyword as a type-position operator with a different meaning has not proven it to be a good approach.

People are continuously confused about the difference between type-position typeof and value-position typeof -- people try to write typeof T in a type position where T is a type parameter, or think that typeof returns something other than a string.