Proposal: Static Typing

Bergi a.d.bergi at web.de
Sun Mar 24 22:26:30 UTC 2019


Hello,
to play the devils advocate: why does JavaScript need static typing?

Your proposal doesn't really answer that. Sure, it mentions tooling and
IDEs that can provide you with type hints and complain on mistakes, but
things like Flow and Typescript do this today already.
What's your goal, to have JS engines run Typescript(-like) code natively
without transpiling? For backwards-compatibility you'd have to do that
anyway, especially if new type system features are introduced incrementally.

What's the point of building this feature into engines? It just provides
additional complexity. Not to mention the difficulty of finding a
suitable type system that is both sophisticated enough to describe all
useful code (not taking away too much flexibility) and simple enough to
understand without a CS degree. And which interfaces well with un-typed
completely dynamic code.

What does "static typing" even mean to you in a dynamic scripting
language? JavaScript is not compiled by the developer, it is run by the
user. Where (when) do you expect types to be checked? Should the engine
throw early errors (during parsing)? During parsing of which parts of
the code, even when "normal" (untyped) code is calling into typed code?
Or do you expect dynamic runtime errors, like when assigning an invalid
value to a "typed variable" or calling a "typed function" with wrong
arguments? Are type definitions completely constant or could they be
mutated/extended/etc dynamically (and what happens when you introduce
new types with `eval` or by loading another script)?

A proposal would need to provide an objective that answers all these
questions, before even considering any particular type system or syntax.

One way to go forward that I can see would be a proposal that reserves a
relatively unrestricted syntax for type annotations (which are already
considered during every grammar amendment anyway, for compatibility with
Flow/Typescript), but not assign any semantics to them and require
engines to simply ignore them. External tooling could then use these
annotations according to its own rules.

kind regards,
  Bergi


More information about the es-discuss mailing list