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

[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.

[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.

[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

[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.

[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.

[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?

[nervgh]

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

What is current status these proposals?

[chicoxyzzy]

@nervgh AFAIK Google has stopped all their work related to SoundScript. Anyway I believe that WebAssembly will expose JavaScript VM's types so it will be possible to use TypeScript not as compiled to JavaScript language but as compiled to WASM language. As well as other languages with static typing.

[chicoxyzzy]

@nervgh AFAIK Google has stopped all their work related to SoundScript. Anyway I believe that WebAssembly will expose JavaScript VM's types so it will be possible to use TypeScript not as compiled to JavaScript language but as compiled to WASM language. As well as other languages with static typing.

[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. 🔗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. 🔗 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. 🔗 Off to new adventures
NaN	Optional Static Typing	@sirisian's proposal	Out of date?

[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. 🔗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. 🔗 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. 🔗 Off to new adventures
NaN	Optional Static Typing	@sirisian's proposal	Out of date?

[PierBover]

Anyone knows of any progress in optional static typing?

[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?

[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 😉

[nicolo-ribaudo]

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

[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.

[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!

[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)

[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

[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.

[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

[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