Optional Static Typing (Part 2)
This strawman have a lot of issues.
- Changing behavior of typeof would probably break the web or cause big troubles (eg. "we can't upgrade library because new objects break our typeof checks").
- Including special types like "uint32" is MUCH bigger task than including optional typing - we need to get types first, then include compile time type checks
- Typed exceptions are inferior to more flexible exception filters
- Your type system is primitive - it's support for functions is almost non-existant (what is your type annotation for foo:uint32 => bar:float32 => anno:string => `${anno} = ${foo+bar}), unions, intersection types, this type, interfaces.
- "use stricter" - it's out of scope of optional static typing
- Multiple dispatch in dynamic language is much bigger problem than one section paragraph.
- Changing behavior of typeof would probably break the web or cause big troubles (eg. "we can't upgrade library because new objects break our typeof checks").
That's why all breaking changes are behind the "use stricter" mode. In the normal mode typeof functions as one would expect with the normal rules. I've separated "use stricter" into another proposal to avoid confusion and keep things independent.
- Including special types like "uint32" is MUCH bigger task than including optional typing - we need to get types first, then include compile time type checks
Agreed, I noticed 64 bit integer operations are already in discussion at stage 0: tc39/proposals/blob/master/stage-0-proposals.md I assume you mean I need to expand the sections 6.1 in my spec changes and detail every type. It's on my list of things to work on. Or are you suggesting another path toward types with a more minimal proposal first?
- Typed exceptions are inferior to more flexible exception filters
One of my friends brought this to my attention already. Maybe I'm missing a big picture thing, but could we not have both? Would introducing typed exceptions block the introduction of exception filters? One of the things I've been looking at are future proposal conflicts so this would be a very interesting one to analyze. If it does conflict I can remove it and add a note in the future concerns section that another proposal will need to make those changes.
- Your type system is primitive - it's support for functions is almost non-existant (what is your type annotation for foo:uint32 => bar:float32 => anno:string => `${anno} = ${foo+bar}), unions, intersection types, this type, interfaces.
let baz:(uint32):(float32):(string):string = foo:uint32 => bar:float32 => anno:string => ${anno} = ${foo+bar};
I have function signatures in the proposal already. Maybe I need to expand the examples though. Would it be possible for you to create issues with examples for the ones you listed and what you'd expect the type annotations to be for each. There's still an open issue that has some complex examples: sirisian/ecmascript-types#2 Someone else was debating the merits of different syntax in that issue.
Also while it might seem primitive the proposal is designed so that it could be expanded later. If you have concerns regarding how it might conflict with more complex type system features in the future I'd be very interested in that. I have a section on generics since people kept bringing it to my attention. Ideally this proposal is somewhat minimal as a first step into types. I fear that if I include anything outside of a minimally viable type system it would be immediately rejected. Presenting the core foundation for a type system with clear paths towards other type system features I think is much easier for the community and implementors to work with.
- "use stricter" - it's out of scope of optional static typing
You're right. I've spun it off into its own proposal. sirisian/ecmascript-use-stricter Can work on that after things are done then and ensure things work independently from any semantic changes. It was created initially because of feedback I got that people wanted to see type annotations as strings and that typeof could be repurposed to be more useful. Needs a lot more thought. So does instanceof for that matter.
- Multiple dispatch in dynamic language is much bigger problem than one section paragraph.
Agreed. Every section relating to it needs to be expanded a lot. Need to find people that are well versed in the subject.
What about TypeScript and Flow? They look like the natural candidates here: already implemented, with real-world projects, tools, and growing communities. Shouldn't the efforts be put on TypeScript/Flow convergence/standardization rather than on a new proposal from scratch.
I've been very slowly expanding a proposal that I started 1 year ago. The current proposal and links to the previous discussion is here:
sirisian/ecmascript-types (If the link gets truncated by esdiscuss.org because of the hyphen view the source to see it).
Since a year ago I've read through the current specification partially analyzing key pieces that would need to be modified, have their wording changed, or that would need to be discussed for static typing to happen. In that effort I've spoken to a lot of developers about certain features, preferences, use cases, and where others want the language to head. I'd rather not see this post devolve into discussions about how TypeScript, CoffeeScript, or WebAssembly exist. I've seen many people try to discuss those as reasons to not evolve ECMAScript, but as has been mentioned before the language is expected to continue to exist and evolve separate from them.
What I would like from the ECMAScript community is anyone that wants to discuss specification issues or expansions to the current proposal. Basically the current pool of people I've been talking to think I've covered the key pieces they wanted to see. If anyone here is interested in the subject and wants to create issues on the github or pull requests to expand sections I'd appreciate it. I'm also looking for anyone that has more intimate knowledge about the grammar. I've been working my way through the grammar, but it's a very daunting and time consuming task for me to create the extra grammar rules or analyze conflicts. Anyone that's done that in the past and would be willing to help it would help the proposal a lot.
Also since I've been asked before, when all the specification sections and grammar are done I'll look for a champion. It's too risky to present a type proposal without first considering everything which is why the proposal needs feedback and work.