<div dir="ltr"><div>Just my personal thoughts on this.</div><div><br></div><div dir="ltr">The way PHP migrated to types has been thought incremental steps, and it worked pretty well.<div><br></div><div>Since types have been demanded by the JS community for a while, I think it'd be key to approach JS types not all at once, but through smaller iterations.</div><div><br></div><div>As example, a proposal with a whole section entitled "Other useless things" would easily diverge focus to stuff the is really not necessary at this point.</div><div><br></div><div>Since types are also pretty much only a tooling convention, starting just with the most basic need/help, and iterate more complex cases later on, would be probably the best way to go.</div><div><br></div><div>Reading though all suggestions, I personally think these would be a no brainer to specify and ship as first iteration:</div><div><ul><li>primitives mean primitives (i.e. `string` means `typeof "string"`, no strings attached)</li><li>Classes and Built-ins mean classes and built-ins (i.e` String` means any `instanceof String`)</li><li>enum could be a new primitive (as in `typeof "enum"`, since static and immutable) but also an expression (like classes), for enums defined as properties/fields of literals and classes</li><li>I actually like the `auto` name more than `any`, but without signature overloads/rides the use case would be too broad, so that maybe we should have a way to also define multiple types (i.e. `const notFullyAuto: String|Object|string = value;`)</li><li>while I know it's pretty common to have `number[]` as type to define an array of numbers, I also don't understand why a new syntax should have already two different ways to define typed array, i.e. `const list:number[]` and `const list:[number]`, so since the latter one is more powerful/flexible, to define also multiple key/value pairs, maybe that's all we need</li></ul><div>With these basics, the JS world would already have a huge change.</div></div><div><br></div><div>Things we might consider, but me might also don't care about, since these behaviors are part of the specs:</div><div><ul><li>`object` would accept `null`, but since there is no `typeof "null"`, the way to ensure `null` won't be there is to use `Object` instead. Are we OK with that?</li><li>`number` would accept `NaN` and `-/Infinity`, but IMO that's the case also without types, if a number is expected. Are we OK with that?</li><li>to avoid confusion with binary `|` operations, maybe multiple types could be wrapped in brackets, so that `const index:{number|string}` might look better?</li></ul><div>That's it for my idea on how this could start moving forward.</div></div><div><br></div><div>Best Regards</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <<a href="mailto:viliuskubilius416@gmail.com">viliuskubilius416@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">This is a proposal for static typing. Here is the github repository link: <a href="https://github.com/CreatorVilius/Proposal-Static-Typing" target="_blank">https://github.com/CreatorVilius/Proposal-Static-Typing</a> <div>I think it would be great thing in JS.</div></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>