(btw the SIMD proposal has been dropped to stage 1, and implementations are not pursuing implementing it in JS for now https://github.com/tc39/proposals/blob/master/inactive-proposals.md)
On Thu, Jan 11, 2018 at 9:18 PM, Brandon Andrews < [email protected]> 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: > https://github.com/Microsoft/TypeScript/issues/4639 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: https://docs.python.org/2/ > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
