Proposal: Optional Static Typing (Part 3)

Jordan Harband ljharb at
Fri Jan 12 05:57:38 UTC 2018

(btw the SIMD proposal has been dropped to stage 1, and implementations are
not pursuing implementing it in JS for now

On Thu, Jan 11, 2018 at 9:18 PM, Brandon Andrews <
warcraftthreeft at> wrote:

> > I'm still yet to read the entire proposal, but with a quick skim, it
> seems to me like this is essentially what Typescript or Flow offers you:
> i.e. an opt-in type system?
> This is in the core of ECMAScript, so the types would be real. The
> implementers would be encouraged to use native hardware types. But yes,
> outside of that it is an opt-in type system. Language built on top of it
> would then benefit from this. I often wonder if languages built on top of
> ES6 haven't limited themselves because types don't exist. That is they'd do
> more, but didn't because the complexity of transpiling. Stuff like this:
> Imagine if ECMAScript
> already had all those types and support function overloading. TypeScript
> could move on and implement more experimental ideas.
> > I'm wondering if you have any good reasons to want there to be a
> standardised static type annotation syntax within ECMAScript instead of a
> "Bring Your Own Type Checker" system. If you do have some thoughts on this,
> you might also want to include that as a preface on your Github's
> README.You have a "Rationale" bit that seems to ignore the existence of
> these existing systems.
> Did you read the rationale? It specifically says:
> > The demand for types as a different approach to code has been so strong
> in the past few years that separate languages have been created to deal
> with the perceived shortcomings.
> More of the rationale was below the types proposed. I've moved it up into
> the rationale since it fits better there. If there's more you think should
> be added I'll include it. I'm trying to keep things concise since it's a
> long proposal. I could go into an explanation that TypeScript and other
> languages are generally just a superset of Javascript and benefit from
> bringing their features closer to the base language and possibly the
> hardware? It seems too obvious to me to write something like that.
> > From a quick read, I'm more in favor of something that's a little more
> restricted to start, something like what Python has. Python has optional
> static type annotations, but the Python interpreter just ignores them. They
> are present purely for the purposes of tooling, and are silently ignored at
> runtime.
> The goal with this proposal is to get essentially native hardware types
> where applicable. All the proposed types have special operator rules, value
> ranges (overflow behavior), and in the case of SIMD very real performance
> impact behind them. While documentation hints are a side-effect, I'm more
> focused instead for pushing ECMAScript toward being a more powerful
> language. Python is a classic example of where data type shortcomings lead
> to unintuitiveness or weird design like:
> library/array.html I'm trying to avoid such things.
> > One of the reasons why I'd prefer a simpler approach to start is that
> TypeScript and Flow, the two main implementations that add syntax, have a
> *very* similar syntax, but have several nuances that would make a heavier
> proposal much harder to accomplish:
> > - Flow has `?Foo` for optional types, TypeScript just uses unions.
> I have a section on unions with a small explanation on why I left it out.
> I kept it simple by only adding nullable types. Right now someone would
> overload or use 'any'.
> > - TypeScript has mapped/index types, where Flow uses special named types.
> I didn't include these.
> > - Flow allows omitted parameter names in function types, TypeScript only
> allows named parameters with implicit `any` types.
> I created an issue to be more explicit about optional and default typed
> parameters and the behavior.
> > - Flow has exact types, TypeScript doesn't.
> I hadn't even considered something like this. It sounds interesting for
> configuration options. They introduce new tokens. Something I'm very much
> avoiding for this initial proposal.
> > - Flow has `opaque type`, TypeScript only has `type`.
> Something to be decided later. Doesn't create breaking changes to add
> later.
> > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
> There's a section on generics and why it isn't included already. I'm with
> you that it's far too complex to add in with initial types. There's no
> breaking changes introduced by adding it later. (Mostly because it
> introduces new tokens which would be a huge deal).
> > - Flow has existential types, TypeScript doesn't.
> I definitely haven't included this. Flow is a few steps ahead of this
> proposal.
> It seems like a lot of these features already aren't included in the
> proposal. I definitely hold your view that the proposal has to be minimal,
> but I think my minimal is functionally minimal. Something that when
> implemented allows developers to experiment and then discussion can
> progress from there to how more features can be added. I'm trying to be
> thourough though as to not harm a future proposal so if any of my decisions
> block something I'm open to changes.
> Most of my thoughts and focus have been on what I think of as the basics.
> How types interact with declarations, functions, classes, destructuring,
> allocation, and control structures. The future consideration sections are
> mostly a catalogue of ensuring that these basic initial features and
> designs will work as the language incorporates other proposals.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list