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.giammar...@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 <
> viliuskubilius...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
