> - 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: https://github.com/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: https://github.com/sirisian/ecmascript-types/issues/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. https://github.com/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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
