Proposal: Optional Static Typing (Part 3)
warcraftthreeft at sbcglobal.net
Mon Jan 15 07:11:28 UTC 2018
> (btw the SIMD proposal has been dropped to stage 1, and implementations are not pursuing implementing it in JS for now tc39/proposals/blob/master/inactive-proposals.md)
Yeah, that seemed predictable. I wanted the SIMD operations to use operators intuitively. That and all the SIMD core types lacked ECMAScript equivalents. Like one expected to be able to write SIMD code and not lose all the speed-up dealing with Number or casts. Was never really sold on the idea of having a float32x4 when the language can't even represent float32 without a TypedArray. Putting the cart before the horse.
> where is this demand coming from?
Also realize I never intended this proposal to be implemented right away. It could take years still. Part of my slight worry as things draw on is that with all these proposals floating around that one of them will change the grammar slightly add new tokens, ASI, or other slight changes and make types infeasible or very inconsistent across the language.
I'm glad you brought that up. I've been thinking about this problem of types changing for a while. Can you write down a bunch of examples and scenarios? It would help to analyze them. (Creating an issue with all of them would be ideal).
Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable. That is referencing a class in say a variable declaration or function signature would freeze the class. Seems a bit extreme of an option though that would cause problems for certain designs or ideas later where people want to add, remove, or update properties. Is it that important? When would a freeze even happen?
I think having a lot of examples would make this easier to analyze.
> People hates writing types
Part of this is to find out how hard a lot of this stuff is. Speaking of type inference someone opened a ticket that started a small discussion: https://github.com/sirisian/ecmascript-types/issues/27 Basically trying to figure out if larger non-Number literals could even be placed into the language without unforeseen issues.
> It might be easier to submit your ideas to these communities than to push a third proposal. At least, a gap analysis would help people who already know these systems.
Isiah, I was looking through my original old post. I must have missed the emails a year ago:
> First, no type checker (TypeScript, Flow, or any other) can fully check the core language (most notably bind, apply, call, and Object.assign).
I've had a section in my spec for typed rest parameters which I think covers a few cases. https://github.com/sirisian/ecmascript-types#rest-parameters Has anything changed with your view on these topics? Or examples and scenarios I should handle in the initial spec?
More information about the es-discuss