Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: Optional Static Typing #45

Closed
ghost opened this issue Jun 14, 2015 · 22 comments

Comments

@ghost
Copy link

commented Jun 14, 2015

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

This comment has been minimized.

Copy link

commented Jun 14, 2015

@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

This comment has been minimized.

Copy link
Author

commented Jun 14, 2015

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

This comment has been minimized.

Copy link

commented Jun 15, 2015

@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

This comment has been minimized.

Copy link
Member

commented Jun 15, 2015

@ghost

This comment has been minimized.

Copy link
Author

commented Jun 15, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jun 15, 2015

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

@rwaldron rwaldron closed this Jun 15, 2015

@nervgh

This comment has been minimized.

Copy link

commented Mar 21, 2016

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

What is current status these proposals?

@azu

This comment has been minimized.

Copy link

commented Mar 27, 2016

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 ?
@2zH 2zH referenced this issue Oct 18, 2017
@PierBover

This comment has been minimized.

Copy link

commented Nov 14, 2017

Anyone knows of any progress in optional static typing?

@NameFILIP

This comment has been minimized.

Copy link

commented May 25, 2018

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

This comment has been minimized.

Copy link
Member

commented May 25, 2018

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

@PierBover

This comment has been minimized.

Copy link

commented May 25, 2018

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

This comment has been minimized.

Copy link

commented May 25, 2018

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

This comment has been minimized.

Copy link
Member

commented May 25, 2018

@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

This comment has been minimized.

Copy link
Member

commented May 25, 2018

@NameFILIP

This comment has been minimized.

Copy link

commented May 26, 2018

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

This comment has been minimized.

Copy link

commented May 28, 2018

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

This comment has been minimized.

Copy link

commented Nov 17, 2018

@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

This comment has been minimized.

Copy link

commented Nov 20, 2018

@PierBover

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.