> 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
