Proposal: Static Typing

Sultan thysultan at gmail.com
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>?) {
return
}

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

On Sun, Mar 24, 2019 at 3:19 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> 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 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
>>
> _______________________________________________
> 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/2142ebf5/attachment.html>


More information about the es-discuss mailing list