Proposal: Static Typing

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Mar 24 12:19:09 UTC 2019


Just my personal thoughts on this.

The way PHP migrated to types has been thought incremental steps, and it
worked pretty well.

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.

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.

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.

Reading though all suggestions, I personally think these would be a no
brainer to specify and ship as first iteration:

   - primitives mean primitives (i.e. `string` means `typeof "string"`, no
   strings attached)
   - Classes and Built-ins mean classes and built-ins (i.e` String` means
   any `instanceof String`)
   - 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
   - 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;`)
   - 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

With these basics, the JS world would already have a huge change.

Things we might consider, but me might also don't care about, since these
behaviors are part of the specs:

   - `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?
   - `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?
   - to avoid confusion with binary `|` operations, maybe multiple types
   could be wrapped in brackets, so that `const index:{number|string}` might
   look better?

That's it for my idea on how this could start moving forward.

Best Regards





On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <
viliuskubilius416 at gmail.com> wrote:

> This is a proposal for static typing. Here is the github repository link:
> https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190324/d77641e2/attachment.html>


More information about the es-discuss mailing list