Ecma262: Request: Optional Static Typing

[ghost]

Hi,

I understand this is an ambitious request, and probably aimed at ES8 or even ES9, but considering the direction many web based technologies are heading, this request definitely makes sense in my mind.

This request is for optional, TypeScript-esque, static typing for ECMAScript.

There are tools and transpilers that already support optional static typing, and Google are also looking at supporting optional static typing directly in their virtual machine with SoundScript. That being said, a formal and specified syntax for optional static typing in ECMAScript would obviously be beneficial in numerous ways. It would allow developers to remove one or more layers from their workflow, therefore improving productivity across the board, and it would also allow virtual machines to produce highly optimized native code from the source files it consumes. I am honestly struggling to think of downsides.

I believe the time is now right to consider adding option static typing to ECMAScript. The language is evolving extremely well now, and optional static typing is one feature that is still sorely missed.

If required, I am willing to compose a full proposal to support this request.

[themihai]

@si-robertson, there is already a proposal[0] [1] for ES7.

[0] https://github.com/tc39/ecma262/blob/master/README.md -> Typed Objects
[1] http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects

[ghost]

Hi @themihai,

Due to the verbosity of that proposal, it is difficult to tell if it is actually for optional static typing. On the surface, it appears to be more of a convoluted boilerplate solution than anything else.

Could someone please confirm if this request and the Typed Objects proposal are, in fact, requesting the same functionality to be added to ECMAScript.

[thomasfoster96]

@si-robertson I'm fairly certain that the Typed Objects proposal isn't anything like TypeScript's static typing. Typed Objects doesn't let you specify the type of a variable or any other sort of type annotations (in function params, etc.), rather it generalises typed arrays to objects (well, objects that act like structs) rather than just one dimensional arrays.

That said, there might be some proposals based on and/or extending Typed Objects that do what you're proposing, but I haven't seen them.

[chicoxyzzy]

check out SoundScript
https://developers.google.com/v8/experiments

[ghost]

Ah, SoundScript, that's the name of the Google tech I couldn't remember.

Thanks Sergey, I will update my original post with the link.

[rwaldron]

SoundScript is the work of TC39 members. Closing this because it's effectively a duplicate of several proposals in progress.

[nervgh]

Closing this because it's effectively a duplicate of several proposals in progress.

What is current status these proposals?

[azu]

I've collected status of Static Typing Proposals.

| Status | Name | Description | Recent Changes |
| --- | --- | :-: | --- |
| NaN | Typed Objects | > All top-level names are defined in a typed objects module. See also Typed Objects Explainer | Out of date. :link:Typed Objects information in proposal table is out of date · Issue #223 · tc39/ecma262 |
| NaN | SoundScript | > We want to try implementing an optional type system for JavaScript, directly in the VM. | V8 will remove support for strong mode. :link: An update on strong mode |
| NaN | Type and Type Annotations | > Reserve syntax used by TypeScript, Flow, etc. for some form of annotation by Jonathan Turner | Jonathan Turner leave Microsoft. :link: Off to new adventures |
| NaN | Optional Static Typing | @sirisian's proposal | ? |

[PierBover]

Anyone knows of any progress in optional static typing?

[NameFILIP]

Currently, there are 2 equally popular ways: Flow and TypeScript. They both are great!

The problem is that two groups of very smart people are working on kind of similar solutions. The whole JS community is divided. I think everyone will clearly benefit from a standardized type system.

Is it possible to bring the relevant Microsoft and Facebook teams together and ask them to consolidate and merge the two approaches pulling out the best parts of each?

[nicolo-ribaudo]

Competition make both of them evolve to try to be better than the other :wink:

[PierBover]

We don't need people making TypeScript or Flow better, or even both teams working together to create TypeFlow or any other thing. Any third party solution will be a workaround with different problems.

The real solution is simply having optional static types natively in the language that will be compatible with the ecosystem and will not require extra configurations.

[NameFILIP]

tl;dr What if each browser had their own scripting language with different features? (wasn't it the reason for creating ECMAScript standard?)

Competition make both of them evolve to try to be better than the other

That's a good point. But it also leads to duplication of effort and wasted human resources of type system developers as well as consumers. Catching bugs in the code is another more healthier motivation to evolve the system. Having a common syntax can at least get rid of duplication for consumers (same type definitions for libraries). This way different implementations can still compete in performance, etc.

having optional static types natively in the language

Yes!

[ljharb]

@NameFILIP both of those teams have conveyed that they think standardizing types of any kind would be a bad idea (at least that’s my current understanding)

[mathiasbynens]

+@samuelgoto

[NameFILIP]

Could you please give more details why it is a bad idea? (@mroch, @gabelevi, @samwgoldman, @ahejlsberg, @DanielRosenwasser, @andy-ms)

I might be missing something, but competing against each other instead of combining forces towards a common goal sounds like a bad idea to me.

[WebReflection]

FWIW, just my 2 cents, I'd love to see progress on this area too and I wouldn't even mind a minimal / incremental implementation similar to what PHP did at its time, where typeof like based hints would already be a reasonable starting point.

In JS, that would be:

const b:boolean = true || false;
const f:function = (() => {}) || function () {} || class {};
const n:number = 123 || 1.23;
const o:object = {} || [] || null;
const s:string = '' || "" || ``;
const u:undefined = void 0;
const y:symbol = Symbol();

from that point on classes, global, scoped, or namespaced, could be a natural follow up.

Why? Well, AFAIK flow and ts are still changing/improving after years of usage so that having the whole thing landing all at once doesn't seem practical or ever happening so that maybe little steps forward, are better than whole thing at once or no steps at all.

P.S. the undefined use case is for any ... it could be called any too, I was just sticking for consistency with the known JS type

[rahbari]

@NameFILIP both of those teams have conveyed that they think standardizing types of any kind would be a bad idea (at least that’s my current understanding)

I think not having optional static types in JS is a bad idea. Just install a npm module which is written in TypeScript and you see there are one JS file per each TS file which leads to a lot of misconceptions in IDEs (even smart one like intellij). And for JS modules which usually use different versions of JSDocs to cover lack of static types, type hinting is not much better.

I have java background and I've really missed code [auto complete - generation - signature - documentation] just with single mouse click. Having no static type was good enough for some event handling in browser back in the old days, but nowadays that web apps got so complicated and npm modules have so many dependencies it is actually a real need to track code development!

The popularity of TS shows high interest rate of developers about optional typing, why not add it to the underlying language and prevent further division in the coming years.

[samuelgoto]

FWIW, we worked on a couple of proposals this year between a few of us.

Here are two different perspectives/proposals with a varying degree of
standardization.

https://github.com/samuelgoto/proposal-optional-types
https://github.com/samuelgoto/proposal-pluggable-types

Sam

On Sat, Nov 17, 2018 at 8:40 AM rahbari [e-mail] wrote:

Install several npm package and

@NameFILIP https://github.com/NameFILIP both of those teams have
conveyed that they think standardizing types of any kind would be a bad
idea (at least that’s my current understanding)

I think not having optional static types in JS is a bad idea. Just install
a npm module which is written in TypeScript and you see there are one JS
file per each TS file which leads to a lot of misconceptions in Smart IDEs.
And for JS modules which usually use different versions of JSDocs to cover
lack of static types type hinting is not much better.

The popularity of TS shows high interest rate of developers about optional
typing, why not add it to the underlying language and prevent further
division.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tc39/ecma262/issues/45#issuecomment-439630045, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAqV6t9KdChrgF37pD-OxC7bTxdE-6NBks5uwDwFgaJpZM4FCnQx
.

--
f u cn rd ths u cn b a gd prgmr !

[PierBover]

FWIW, we worked on a couple of proposals this year between a few of us. Here are two different perspectives/proposals with a varying degree of standardization.

(Not sure if this is the place to discuss this. If not, please let me know.)

In those 2 proposals, is there a justification for non nullable types or multiple types? For example in making things easier for the type checker and adding performance?

All ES inspired languages with optional types support nullable types. TypeScript, ES4/AS3, and Haxe (for some targets). In C# and Java reference types are also nullable, while primitives are not.

As for multiple types, I personally think that would only add more confusion.

[bakkot]

In C# and Java reference types are also nullable

In C#'s case, not for much longer. Same in TypeScript if you pass --strictNullChecks (which you absolutely should).

"types can be made nullable by using explicitly the union type" (or possibly some syntax sugar meaning the same thing) is a much better approach than "all types are implicitly | null".

Edit: the right place for these discussions would be as an issue on the proposal repo, rather than this thread.

[samuelgoto]

That s probably best to follow up in those repos themselves. I'd be happy
to have that discussion there .

(apologies for the brevity, sent from phone)

On Tue, Nov 20, 2018, 10:51 AM Pier Bover <[email protected] wrote:

FWIW, we worked on a couple of proposals this year between a few of us.
Here are two different perspectives/proposals with a varying degree of
standardization.

(Not sure if this is the place to discuss this. If not, please let me
know.)

In those 2 proposals, is there a justification for non nullable types or
multiple types? For example in making things easier for the type checker
and adding performance?

All ES inspired languages with optional types support nullable types.
TypeScript, ES4/AS3, and Haxe (for some targets). In C# and Java reference
types are also nullable, while primitives are not.

As for multiple types, I personally think that would only add more
confusion.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tc39/ecma262/issues/45#issuecomment-440388676, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAqV6kIdcu58lALpRe7xGGpd67SCpbZEks5uxE8XgaJpZM4FCnQx
.

[Vanuan]

It's interesting that static type annotations seem to be cursed in EcmaScript.

• The first draft of optional type annotations dates back to ES4 (1999-2003).
• Then Adobe's ActionScript (1999-2006) entered the stage and died a slow death.
• Static type analyzers for dynamic languages were booming in 2005-2015. A lot of different comment-based syntaxis introduced by IDE companies.
• Microsoft made TypeScript public in 2012 and it has grown tremendously.
• Facebook's Flow analyzer was introduced in 2014.
• Other dynamic languages embraced some form of type annotation syntax: Kotlin, Python.
• Google has been trying to introduce optional types to the web since 2011 with Dart.

Is it a time yet for ESNext type annotations?

[Jack-Works]

TypeScript is now de facto typed version of JavaScript with a growing community and good IDE support. Isn't that enough? 🤔

[Vanuan]

@Jack-Works no, because you have to deploy multiple versions of npm packages, for both typed and non-typed JS. Now, add the "type: module"/michael jackson files into the mix. This is not sustainable. JS should support the type annotation syntax even if it doesn't have any runtime meaning.

[Vanuan]

Of course, the threat is that when the type annotation syntax is used in real websites, you won't be able to introduce runtime errors later.
This can be mitigated by introducing some experimental syntax flag to prevent browsers from supporting it without transpiling.