Proposal: Static Typing

Sultan thysultan at
Sun Mar 24 17:29:21 UTC 2019

Counter proposal: A uniform signature for types, denoted by:

const name: primitive-type<arguments...>?;

Where primitive types are denoted as:

const name: symbol;
const name: string;
const name: number;
const name: object;
const name: boolean;
const name: function;

And types can later be extended to afford additional meta data as needed:

const name: string<10>; // string of length 10
const name: number<float>; // floating point number, as opposed to BigInt

const name: object<[]>; // array object
const name: object<Node>; // Node object

Union types can get added later, and denoted as:

const name: union<string, number>;

Functions can later be afforded return and argument types as denoted by:

function<void> fn (a: object<[], number>, b: string<10>?) {

const fn: function<void> = (a: object<[], number>, b: string<10>?) => {

On Sun, Mar 24, 2019 at 3:19 PM Andrea Giammarchi <
andrea.giammarchi at> wrote:

> 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> wrote:
>> This is a proposal for static typing. Here is the github repository link:
>> I think it would be great thing in JS.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list