ES8 Proposal: Optional Static Typing (Brandon Andrews)

# Ron Waldon (9 years ago)

One of the first complications with types is typeof's behavior. All of

the above types would return their string conversion including bool. (In my experience "boolean" is seen as verbose among C++ and C# developers. Breaking this part of Java's influence probably wouldn't hurt to preserve consistency for the future).

I can't see typeof changing at all. "Verbose" output doesn't seem like a problem that is worth breaking backwards-compatibility to solve.

We've seen a new pattern in ES5 and continued now with ES2015:

  • Array.isArray()
  • Number.isNumber()
  • Object.isObject()
  • etc...

Perhaps this pattern just needs to be continued for all types, including the TypedArrays (if not already being considered). I personally like this pattern because it doesn't change typeof, and it provides an less-verbose alternative, and it is able to be polyfilled because it's an API addition and not a syntax change.

Other than this, I like the idea of optional static typing. I am a little ambivalent about the syntax. I can't decide if it literally should just be decorators, or if it deserves something more special.

Perhaps all we really need here is the ability to name decorators using Symbols. This way, ECMA / TC39 can use real data over time to add type decorator Symbols for the 90% case without conflicting with future code. By virtue of being built-in Symbol-named decorators, they should still be able to natively-optimised and statically-analysed.

# Anne van Kesteren (9 years ago)

On Sun, Jul 19, 2015 at 10:05 PM, Ron Waldon <jokeyrhyme at gmail.com> wrote:

We've seen a new pattern in ES5 and continued now with ES2015:

  • Array.isArray()
  • Number.isNumber()
  • Object.isObject()
  • etc...

I can only find the first in this list.

Perhaps this pattern just needs to be continued for all types, including the TypedArrays (if not already being considered). I personally like this pattern because it doesn't change typeof, and it provides an less-verbose alternative, and it is able to be polyfilled because it's an API addition and not a syntax change.

Note lists.w3.org/Archives/Public/public-script-coord/2013JulSep/thread.html#msg105 where this was discussed previously and not really met with acceptance.