Home

Awesome

ECMAScript Proposal: Optional Static Typing

Current status of this proposal is -1. It's in a theoretical state at the moment to better understand how types could function in Javascript and the long-term future benefits or complications they could cause to future proposals.

Rationale

With TypedArrays and classes finalized, ECMAScript is in a good place to finally discuss types again. The demand for types as a different approach to code has been so strong in the past few years that separate languages have been created to deal with the perceived shortcomings. Types won't be an easy discussion, nor an easy addition, since they touch a large amount of the language; however, they are something that needs rigorous discussion.

The types described below bring ECMAScript in line or surpasses the type systems in most languages. For developers it cleans up a lot of the syntax, as described later, for TypedArrays, SIMD, and working with number types (floats vs signed and unsigned integers). It also allows for new language features like function overloading and a clean syntax for operator overloading. For implementors, added types offer a way to better optimize the JIT when specific types are used. For languages built on top of Javascript this allows more explicit type usage and closer matching to hardware.

The explicit goal of this proposal is to not just to give developers static type checking. It's to offer information to engines to use native types and optimize callstacks and memory usage. Ideally engines could inline and optimize code paths that are fully typed offering closer to native performance.

Native/Runtime Typing vs Type Annotations aka Types as Comments

This proposal covers a native/runtime type system and associated language features. That is the types introduced are able to be used by the engine to implement new features and optimize code. Errors related to passing the wrong types throws TypeError exceptions meaning the types are validated at runtime.

A type annotation or types as comments proposal treats type syntax as comments with no impact on the behavior of the code. It's primarily used with bundlers and IDEs to run checks during development. See the Type Annotations proposal for more details.

Types Proposed

Since it would be potentially years before this would be implemented this proposal includes a new keyword enum for enumerated types and the following types:

number
boolean
string
object
symbol
int.<N>

<details> <summary>Expand for all the int shorthands.</summary> 
type int8 = int.<8>;
type int16 = int.<16>;
type int32 = int.<32>;
type int64 = int.<64>;
</details>

uint.<N>

<details> <summary>Expand for all the uint shorthands.</summary> 
type uint8 = uint.<8>;
type uint16 = uint.<16>;
type uint32 = uint.<32>;
type uint64 = uint.<64>;
</details>

bigint
float16, float32, float64, float80, float128
decimal32, decimal64, decimal128
vector.<T, N>

<details> <summary>Expand for all the SIMD shorthands.</summary> 
type boolean1 = uint.<1>;
type boolean8 = vector.<boolean1, 8>;
type boolean16 = vector.<boolean1, 16>;
type boolean32 = vector.<boolean1, 32>;
type boolean64 = vector.<boolean1, 64>;

type boolean8x16 = vector.<boolean8, 16>;
type boolean16x8 = vector.<boolean16, 8>;
type boolean32x4 = vector.<boolean32, 4>;
type boolean64x2 = vector.<boolean64, 2>;
type boolean8x32 = vector.<boolean8, 32>;
type boolean16x16 = vector.<boolean16, 16>;
type boolean32x8 = vector.<boolean32, 8>;
type boolean64x4 = vector.<boolean64, 4>;
type int8x16 = vector.<int8, 16>;
type int16x8 = vector.<int16, 8>;
type int32x4 = vector.<int32, 4>;
type int64x2 = vector.<int64, 2>;
type int8x32 = vector.<int8, 32>;
type int16x16 = vector.<int16, 16>;
type int32x8 = vector.<int32, 8>;
type int64x4 = vector.<int64, 4>;
type uint8x16 = vector.<uint8, 16>;
type uint16x8 = vector.<uint16, 8>;
type uint32x4 = vector.<uint32, 4>;
type uint64x2 = vector.<uint64, 2>;
type uint8x32 = vector.<uint8, 32>;
type uint16x16 = vector.<uint16, 16>;
type uint32x8 = vector.<uint32, 8>;
type uint64x4 = vector.<uint64, 4>;
type float32x4 = vector.<float32, 4>;
type float64x2 = vector.<float64, 2>;
type float32x8 = vector.<float32, 8>;
type float64x4 = vector.<float64, 4>;
</details>

rational
complex
any

These types once imported behave like a const declaration and cannot be reassigned.

Variable Declaration With Type

This syntax is taken from ActionScript and other proposals over the years. It's subjectively concise, readable, and consistent throughout the proposal.

var a: Type = value;
let b: Type = value;
const c: Type = value;

typeof Operator

typeof's behavior is essentially unchanged. All numerical types return "number". SIMD, rational, and complex types return "object".

let a: uint8 = 0; // typeof a == "number"
let b: uint8|null = 0; // typeof b == "number"
let c: [].<uint8> = []; // typeof c == "object"
let d: (uint8) => uint8 = x => x * x; // typeof d == "function"

TODO: Should there be a way to get the specific type? See https://github.com/sirisian/ecmascript-types/issues/60

instanceof Operator

THIS SECTION IS A WIP

if (a instanceof uint8) {}

Also this would be nice for function signatures.

if (a instanceof (uint8) => uint8) {}

That would imply Object.getPrototypeOf(a) === ((uint8):uint8).prototype.

I'm not well versed on if this makes sense though, but it would be like each typed function has a prototype defined by the signature.

Union and Nullable Types

All types except any are non-nullable. The syntax below creates a nullable uint8 typed variable:

let a: uint8 | null = null;

A union type can be defined like:

let a: uint8 | string = 'a';

The | can placed at the beginning when defining a union across multiple lines.

type a =
  | b
  | c;

Intersection types

// TODO

any Type

Using any|null would result in a syntax error since any already includes nullable types. As would using [].<any> since it already includes array types. Using just [] would be the type for arrays that can contain anything. For example:

let a:[];

Variable-length Typed Arrays

A generic syntax .<T> is used to type array elements.

let a: [].<uint8>; // []
a.push(0); // [0]
let b: [].<uint8> = [0, 1, 2, 3];
let c: [].<uint8> | null; // null
let d: [].<uint8 | null> = [0, null]; // Not sequential memory
let e: [].<uint8 | null>|null; // null // Not sequential memory

The index operator doesn't perform casting just to be clear so array objects even when typed still behave like objects.

let a: [].<uint8> = [0, 1, 2, 3];
a['a'] = 0;
'a' in a; // true
delete a['a'];

Fixed-length Typed Arrays

let a: [4].<uint8>; // [0, 0, 0, 0]
// a.push(0); TypeError: a is fixed-length
// a.pop(); TypeError: a is fixed-length
a[0] = 1; // valid
// a[a.length] = 2; Out of range
let b: [4].<uint8> = [0, 1, 2, 3];
let c: [4].<uint8> | null; // null

Typed arrays would be zero-ed at creation. That is the allocated memory would be set to all zeroes.

Also all fixed-length typed arrays use a SharedArrayBuffer by default.

Mixing Variable-length and Fixed-length Arrays

function f(c:boolean):[].<uint8> { // default case, return a resizable array
  let a: [4].<uint8> = [0, 1, 2, 3];
  let b: [6].<uint8> = [0, 1, 2, 3, 4, 5];
  return c ? a : b;
}

function f(c:boolean):[6].<uint8> { // Resizes a if c is true
  let a: [4].<uint8> = [0, 1, 2, 3];
  let b: [6].<uint8> = [0, 1, 2, 3, 4, 5];
  return c ? a : b;
}

Any Typed Array

let a: []; // Using [].<any> is a syntax error as explained before
let b: [] | null; // null

Deleting a typed array element results in a type error:

const a: [].<uint8> = [0, 1, 2, 3];
// delete a[0]; TypeError: a is fixed-length

Array length Type And Operations

Valid types for defining the length of an array are int8, int16, int32, int64, uint8, uint16, uint32, and uint64.

[].<T, Length = uint32>

Syntax uses the second parameter for the generic:

let a: [].<uint8, int8>  = [0, 1, 2, 3, 4];
let b = a.length; // length is type int8

let a: [5].<uint8, uint64> = [0, 1, 2, 3, 4];
let b = a.length; // length is type uint64 with value 5

let n = 5;
let a: [n].<uint8, uint64> = [0, 1, 2, 3, 4];
let b = a.length; // length is type uint64 with value 5

Setting the length reallocates the array truncating when applicable.

let a: [].<uint8> = [0, 1, 2, 3, 4];
a.length = 4; // [0, 1, 2, 4]
a.length = 6; // [0, 1, 2, 4, 0, 0]

let a:[5].<uint8> = [0, 1, 2, 3, 4];
// a.length = 4; TypeError: a is fixed-length

Array Views

Like TypedArray views, this array syntax allows any array, even arrays of typed objects to be viewed as different objects.

let view = [].<Type>(buffer [, byteOffset [, byteElementLength]]);

let a: [].<uint64> = [1];
let b = [].<uint32>(a, 0, 8);

By default byteElementLength is the size of the array's type. So [].<uint32>(...) would be 4 bytes. The byteElementLength can be less than or greater than the actual size of the type. For example (refer to the Class section):

class A {
  a:uint8;
  b:uint16;
  constructor(value) {
    this.b = value;
  }
}
const a:[].<A> = [0, 1, 2];
const b = [].<uint16>(a, 1, 3); // Offset of 1 byte into the array and 3 byte length per element
b[2]; // 2

Multidimensional and Jagged Array Support Via User-defined Index Operators

Rather than defining index functions for various multidimensional and jagged array implementations the user is given the ability to define their own. More than one can be defined as long as they have unique signatures.

An example of a user-defined index to access a 16 element grid with (x, y) coordinates:

class GridArray<N: uint32> extends [N].<uint8> {
  get operator[](x: uint32, y: uint32) {
    return ref this[y * 4 + x];
  }
}
const grid = new GridArray<16>();
grid[2, 1] = 10;

class GridArray<N: uint32> extends [N].<uint8> {
  get operator[](i: uint32) {
    return ref this[i];
  }
  get operator[](x: uint32, y: uint32) {
    return ref this[y * 4 + x];
  }
}
const grid = new GridArray<16>();
grid[0] = 10;
grid[2, 1] = 10;

For a variable-length array it works as expected:

class GridArray extends [].<uint8> {
  get operator[](x: uint32, y: uint32, z: uint32) {
    return ref this[z * 4**2 + y * 4 + x];
  }
}
const grid = new GridArray();
grid.push(...);
grid[1, 2] = 10;

Views also work as expected allowing one to apply custom indexing to existing arrays:

const grid = new [100].<uint8>();
const gridView = new GridArray(grid);

Implicit Casting

The default numeric type Number would convert implicitly with precedence given to decimal128/64/32, float128/80/64/32/16, uint64/32/16/8, int64/32/16/8. (This is up for debate). Examples are shown later with class constructor overloading.

function f(a: float32) {}
function f(a: uint32) {}
f(1); // float32 called
f(1 as uint32); // uint32 called

It's also possible to use operator overloading to define implicit casts. The following casts to a heterogeneous tuple:

class A {
    x: number;
    y: number;
    z: string;
    operator [number, number, string]() {
        return [this.x, this.y, this.z];
    }
}

const a = new A();
const [x, y, z] = A;

Explicit Casting

let a := 65535 as uint8; // Cast taking the lowest 8 bits so the value 255, but note that a is still typed as any
let b: uint8 = 65535; // Same as the above

Many truncation rules have intuitive rules going from larger bits to smaller bits or signed types to unsigned types. Type casts like decimal to float or float to decimal would need to be clear.

Function signatures with constraints

A typed function defaults to a return type of undefined. In almost every case where undefined might be needed it's implicit and defining it is not allowed.

function f() {} // return type any
// function f(a: int32) { return 10; } // TypeError: Function signature for F, undefined, does not match return type, number.
function g(a: int32) {} // return type undefined
// function g(a: int32):undefined {} // TypeError: Explicitly defining a return type of undefined is not allowed.

The only case where undefined is allowed is for functions that take no parameters where the return type signals it's a typed function.

function f(): undefined {}

An example of applying more parameter constraints:

function f(a: int32, b: string, c: [].<bigint>, callback: (boolean, string) => string = (b, s = 'none') => b ? s : ''): int32 {}

Optional Parameters

While function overloading can be used to handle many cases of optional arguments it's possible to define one function that handles both:

function f(a: uint32, b?: uint32) {}
f(1);
f(1, 2);

Typed Arrow Functions

let a: (int32, string) => string; // hold a reference to a signature of this type
let b: (); // undefined is the default return type for a signature without a return type
let c = (s: string, x: int32) => s + x; // implicit return type of string
let d = (x: uint8, y: uint8): uint16 => x + y; // explicit return type
let e = x: uint8 => x + y; // single parameter

Like other types they can be made nullable. An example showing an extreme case where everything is made nullable:

let a: ((number | null) => number | null) | null = null;

This can be written also using the interfaces syntax, which is explained later:

let a: { (uint32 | null): uint32; } | null = null;

Integer Binary Shifts

let a: int8 = -128;
a >> 1; // -64, sign extension
let b: uint8 = 128;
b >> 1; // 64, no sign extension as would be expected with an unsigned type

Integer Division

let a: int32 = 3;
a /= 2; // 1

Type Propagation to Literals

In ECMAScript currently the following values are equal:

let a = 2**53;
a == a + 1; // true

The changes below expand the representable numbers by propagating type information when defined.

Types propagate to the right hand side of any expression.

let a: uint64 = 2**53;
a == a + 1; // false
    
let b:uint64 = 9007199254740992 + 9007199254740993; // 18014398509481985

Types propagate to arguments as well.

function f(a: uint64) {}
f(9007199254740992 + 9007199254740993); // 18014398509481985

Consider where the literals are not directly typed. In this case they are typed as Number as expected:

function f(a: uint64) {}
const a = 9007199254740992 + 9007199254740993;
f(a); // 18014398509481984

In typed code this behavior of propagating types to literals means that suffixes aren't required by programmers.

This proposal introduces one breaking change related to the BigInt function. When passing an expression the signature uses bigint(n:bigint).

//BigInt(999999999999999999999999999999999999999999); // Current behavior is 1000000000000000044885712678075916785549312n
BigInt(999999999999999999999999999999999999999999); // New Behavior: 999999999999999999999999999999999999999999n

Alternatively BigInt could remain as it is and bigint would have this behavior. The change is only made to avoid confusion.

This behavior is especially useful when using the float and decimal types.

const a: decimal128 = 9.999999999999999999999999999999999;

Typed Array Propagation to Arrays

Identically to how types propagate to literals they also propagate to arrays. For example, the array type is propagated to the right side:

const a:[].<bigint> = [999999999999999999999999999999999999999999];

This can be used to construct instances using implicit casting:

class MyType {
  constructor(a: uint32) {
  }
  constructor(a: uint32, b: uint32) {
  }
}
let a:[].<MyType> = [1, 2, 3, 4, 5];

Implicit array casting already exists for single variables as defined above. It's possible one might want to compactly create instances. The following new syntax allows this:

let a: [].<MyType> = [(10, 20), (30, 40), 10];

This would be equivalent to:

let a: [].<MyType> = [new MyType(10, 20), new MyType(30, 40), 10];

Due to the very specialized syntax it can't be introduced later. In ECMAScript the parentheses have defined meaning such that [(10, 20), 30] is [20, 30] when evaluated. This special syntax takes into account that an array is being created requiring more grammar rules to specialize this case.

Initializer lists work well with SIMD to create compact arrays of vectors:

let a: [].<float32x4> = [
  (1, 2, 3, 4), (1, 2, 3, 4), (1, 2, 3, 4),
  (1, 2, 3, 4), (1, 2, 3, 4), (1, 2, 3, 4),
  (1, 2, 3, 4), (1, 2, 3, 4), (1, 2, 3, 4)
];

Since this works for any type the following works as well. The typed array is propagated to the argument.

function f(a: [].<float32x4>) {
}
f([(1, 2, 3, 4)]);

Destructuring Assignment Casting

Array destructuring with default values:

[a: uint32 = 1, b: float32 = 2] = f();

Object destructuring with default values:

{ (a: uint8) = 1, (b: uint8) = 2 } = { a: 2 };

Object destructuring with default value and new name:

let { (a: uint8): b = 1 } = { a: 2 }; // b is 2

Assigning to an already declared variable:

let b:uint8;
({ a: b = 1 } = { a: 2 }); // b is 2

Destructuring with functions:

(({ (a: uint8): b = 0, (b: uint8): a = 0}, [c: uint8]) =>
{
    // a = 2, b = 1, c = 0
})({a: 1, b: 2}, [0]);

Nested/deep object destructuring:

const { a: { (a2: uint32): b, a3: [, c: uint8] } } = { a: { a2: 1, a3: [2, 3] } }; // b is 1, c is 3

Destructuring objects with arrays:

const { (a: [].<uint8>) } = { a: [1, 2, 3] } }; // a is [1, 2, 3] with type [].<uint8>

Array Rest Destructuring

let [a: uint8, ...[b: uint8]] = [1, 2];
b; // 2

A recursive spread version that is identical, but shown for example:

let [a: uint8, ...[...[b: uint8]]] = [1, 2];
b; // 2

Typing arrays:

let [a: uint8, ...b: uint8] = [1, 2];
b; // [2]

Object Rest Destructuring

https://github.com/tc39/proposal-object-rest-spread

let { (x: uint8), ...(y:{ (a: uint8), (b: uint8) }) } = { x: 1, a: 2, b: 3 };
x; // 1
y; // { a: 2, b: 3 }

Renaming:

let { (x: uint8): a, ...(b:{ (a: uint8): x, (b: uint8): y }) } = { x: 1, a: 2, b: 3 };
a; // 1
b; // { x: 2, y: 3 }

Typed return values for destructuring

Basic array destructuring:

function f(): [uint8, uint32] {
  return [1, 2];
}
const [a, b] = f();

Array defaults

function f(): [uint8, uint32 = 10] {
  return [1];
}
const [a, b] = f(); // a is 1 and b is 10

Basic object destructuring:

function f(): { a: uint8; b: float32; } {
  return { a: 1, b: 2 };
}
const { a, b } = f();

Object defaults:

function f():{ a: uint8; b: float32 = 10; } {
  return { a: 1 };
}
const { a, b } = f(); // { a: 1, b: 10 }

Overloaded example for the return type:

function f(): [int32] {
  return [1];
}
function f(): [int32, int32] {
  return [2, 3];
}
function f(): { a: uint8; b: float32; } {
  return { a: 1, b: 2 };
}
const [a] = f(); // a is 1
const [b, ...c] = f(); // b is 2 and c is [3]
const { a: d, b: e } = f(); // d is 1 and e is 2

See the section on overloading return types for more information: https://github.com/sirisian/ecmascript-types#overloading-on-return-type

Explicitly selecting an overload:

function f(): [int32] {
  return [1];
}
function f(): [float32] {
  return [2.0];
}
const [a: int32] = f();
const [a: float32] = f();

TypeError example:

function f(): [int32, float32] {
  // return [1]; // TypeError, expected [int32, float32]
}

Interfaces

Interfaces can be used to type objects, arrays, and functions. This allows users to remove redundant type information that is used in multiple places such as in destructuring calls. In addition, interfaces can be used to define contracts for classes and their required properties.

Object Interfaces

interface IExample {
  a: string;
  b: (uint32) => uint32;
  ?c: any; // Optional property. A default value can be assigned like:
  // c: any = [];
}

function f(): IExample {
  return { a: 'a', b: x => x };
}

Similar to other types an object interface can be made nullable and also made into an array with [].

function f(a: [].<IExample> | null) {
}

An object that implements an interface cannot be modified in a way that removes that implementation.

interface IExample {
  a: string;
}
function f(a: IExample) {
  // delete a.a; // TypeError: Property 'a' in interface IExample cannot be deleted
}
f({ a: 'a' });

In this example the object argument is cast to an IExample since it matches the shape.

A more complex example:

interface A { a: uint32; }
interface B { a: string; }
function f(a: A) {}
function f(b: B) {}
function g(a: A | B) {
  a.a = 10; // "10" because parameter 'a' implements B
}
g({ a: 'a' });

Array Interfaces

interface IExample [
  string,
  uint32,
  ?string // Optional item. A default value can be assigned like:
  // ?string = 10
]

function f(): IExample {
  return ['a', 1];
}

Function Interfaces

With function overloading an interface can place multiple function constraints. Unlike parameter lists in function declarations the type precedes the optional name.

interface IExample {
  (string, uint32); // undefined is the default return type
  (uint32);
  ?(string, string): string; // Optional overload. A default value can be assigned like:
  // (string, string): string = (x, y) => x + y;
}

function f(a:IExample) {
  a('a', 1);
  // a('a'); // TypeError: No matching signature for (string).
}

Signature equality checks ignore renaming:

interface IExample {
  ({ (a: uint32) }): uint32
}
function f(a: IExample) {
  a({ a: 1 }); // 1
}
f(({(a:uint32):b}) => b); // This works since the signature check ignores any renaming

An example of taking a typed object:

interface IExample {
  ({ a: uint32; }): uint32;
}
function f(a:IExample) {
  a({ a: 1 }); // 1
}
f(a => a.a);

Argument names in function interfaces are optional. This to support named arguments. Note that if an interface is used then the name can be changed in the passed in function. For example:

interface IExample {
  (string = 5, uint32: named);
}
function f(a: IExample) {
  a(named: 10); // 10
}
f((a, b) => b);

The interface in this example defines the mapping for "named" to the second parameter.

It might not be obvious at first glance, but there are two separate syntaxes for defining function type constraints. One without an interface, for single non-overloaded function signatures, and with interface, for either constraining the parameter names or to define overloaded function type constraints.

function (a: (uint32, uint32)) {} // Using non-overloaded function signature
function (a: { (uint32, uint32); }) {} // Identical to the above using Interface syntax

Most of the time users will use the first syntax, but the latter can be used if a function is overloaded:

function (a: { (uint32); (string); }) {
  a(1);
  a('a');
}

Nested Interfaces

interface IA {
  a: uint32;
}
interface IB {
  (IA);
}
/*
interface IB {
    ({ a: uint32; });
}
*/

Extending Interfaces

Extending object interfaces:

interface A {
  a: string;
}
interface B extends A {
  b: (uint32) => uint32;
}
function f(c: B) {
  c.a = 'a';
  c.b = b => b;
}

Extending function interfaces:

interface A {
  (string);
}
interface B extends A {
  (string, string);
}
function f(a: B) {
  a('a');
  a('a', 'b');
}

Implementing Interfaces

interface A {
  a: uint32;
  b(uint32): uint32;
}
class B {
}
class C extends B implements A {
  b(a) {
    return a;
  }
}
const a = new C();
a.a = a.b(5);

Note that since b isn't overloaded, defining the type of the member function b in the class C isn't necessary.

Once a class implements an interface it cannot remove that contract. Attempting to delete the member a or the method b would throw a TypeError.

Typed Assignment

A variable by default is typed any meaning it's dynamic and its type changes depending on the last assigned value. As an example one can write:

let a = new MyType();
a = 5; // a is type any and is 5

If one wants to constrain the variable type they can write:

let a:MyType = new MyType();
// a = 5; // Equivelant to using implicit casting: a = MyType(5);

This redundancy in declaring types for the variable can be removed with a typed assignment:

let a := new MyType(); // a is type MyType
// a = 5; // Equivelant to using implicit casting: a = MyType(5);

This new form of assignment is useful with both var and let declarations. With const it has no uses:

const a = new MyType(); // a is type MyType
const b: MyType = new MyType(); // Redundant, b is type MyType even without explicitly specifying the type
const c := new MyType(); // Redundant, c is type MyType even without explicitly specifying the type
const d: MyType = 1; // Calls a matching constructor
const e: uint8 = 1; // Without the type this would have been typed Number
class A {}
class B extends A {}
const f: A = new B(); // This might not even be useful to allow

This assignment also works with destructuring:

let { a, b } := { (a: uint8): 1, (b: uint32): 2 }; // a is type uint8 and b is type uint32

Function Overloading

All function can be overloaded if the signature is non-ambiguous. A signature is defined by the parameter types and return type. (Return type overloading is covered in a subsection below as this is rare).

function f(x: [].<int32>): string { return 'int32'; }
function f(s: [].<string>): string { return 'string'; }
f(['test']); // "string"

Up for debate is if accessing the separate functions is required. Functions are objects so using a key syntax with a string isn't ideal. Something like F['(int32[])'] wouldn't be viable. It's possible Reflect could have something added to it to allow access.

Signatures must match for a typed function:

function f(a: uint8, b: string) {}
// f(1); // TypeError: Function F has no matching signature

Adding a normal untyped function acts like a catch all for any arguments:

function f() {} // untyped function
function f(a: uint8) {}
f(1, 2); // Calls the untyped function

If the intention is to created a typed function with no arguments then setting the return value is sufficient:

function f() {}
// f(1); // TypeError: Function F has no matching signature

Duplicate signatures are not allowed:

function f(a:uint8) {}
// function f(a: uint8, b: string = 'b') {} // TypeError: A function declaration with that signature already exists
f(8);

Be aware that rest parameters can create identical signatures also.

function f(a: float32): void {}
// function f(...a: [].<float32>): void {} // TypeError: A function declaration with that signature already exists

See the Type Records page for more information on signatures.

Overloading on Return Type

function f(): uint32 {
  return 10;
}
function f(): string {
  return "10";
}
// f(); // TypeError: Ambiguous signature for F. Requires explicit left-hand side type or cast.
const a: string = f(); // "10"
const b: uint32 = f(); // 10

function g(a:uint32):uint32 {
  return a;
}
g(f()); // 10

function h(a:uint8) {}
function h(a:string) {}
// h(f()); // TypeError: Ambiguous signature for F. Requires explicit left-hand side type or cast.
h(uint32(f()));

Overloading return types is especially useful on operators. Take SIMD operators, represented here by their intrinsic, that can return both a vector register or mask:

__m128i _mm_cmpeq_epi32 (__m128i a, __m128i b)
__mmask8 _mm_cmpeq_epi32_mask (__m128i a, __m128i b)

Notice Intel differentiates signatures by adding _mask. When translated to real types with operators they are identical however:

//const something = int32x4(0, 1, 2, 3) === int32x4(0, 1, 3, 2); // TypeError: Ambiguous return type. Requires explicit cast to int32x4 or boolean8

With overloaded return types we can support both signatures:

const a: int32x4 = int32x4(0, 1, 2, 3) === int32x4(0, 1, 3, 2);
const b: boolean8 = int32x4(0, 1, 2, 3) === int32x4(0, 1, 3, 2);

For reference, the operators look like:

operator<(v: int32x4): int32x4 {}
operator<(v: int32x4): boolean8 {}

Typed Promises

Typed promises use a generic syntax where the resolve and reject type default to any.

Promise<R extends any, E extends any>

const a = new Promise.<uint8, Error>((resolve, reject) => {
  resolve(0); // or throw new Error();
});

To keep things consistent, the async version has the same return type.

async function f(): Promise.<uint8, Error> {
  return 0;
}

If a Promise never throws anything then the following can be used:

async function f(): Promise.<uint8, undefined> {
  return 0;
}

Right now there's no check except the runtime check when a function actually throws to validate the exception types. It is feasible however that the immediate async function scope could be checked to match the type and generate a TypeError if one is found even for codepaths that can't resolve. This is stuff one's IDE might flag.

Overloading Async Functions and Typed Promises

While async functions and synchronous functions can overload the same name, they must have unique signatures.

async function f(): Promise.<any, Error> {}
/* function f(): Promise.<any, Error> { // TypeError: A function with that signature already exists
    return new Promise.<any, Error>((resolve, reject) => {});
} */
await f();

Refer to the try catch section on how different exception types would be explicitly captured: https://github.com/sirisian/ecmascript-types#try-catch

Generator Overloading

WIP: I don't like this syntax.

var o = {};
o[Symbol.iterator] =
[
  function* (): int32 {
    yield* [1, 2, 3];
  },
  function* (): [int32, int32] {
    yield* [[0, 1], [1, 2], [2, 3]];
  }
];

[...o:int32]; // [1, 2, 3] Explicit selection of the generator return signature
for (const a:int32 of o) {} // Type is optional in this case
[...o:[int32, int32]]; // [[0, 1], [1, 2], [2, 3]]
for (const [a:int32, b:int32] of o) {} // Type is optional in this case

I'd rather do something like:

*operator...(): int32 {
  yield* [1, 2, 3];
}
*operator...(): [int32, int32] {
  yield* [[0, 1], [1, 2], [2, 3]];
}

Object Typing

Syntax:

let o = { (a: uint8): 1 };

This syntax is used because like destructuring the grammar cannot differentiate the multiple cases where types are included or excluded resulting in an ambiguous grammar. The parenthesis cleanly solves this.

let a = [];
let o = { a };
o = { a: [] };
o = { (a: [].<uint8>) }; // cast a to [].<uint8>
o = { (a: [].<uint8>):[] }; // new object with property a set to an empty array of type uint8[]

This syntax works with any arrays:

let o = { a: [] }; // Normal array syntax works as expected
let o = { (a: []): [] }; // With typing this is identical to the above

Object.defineProperty and Object.defineProperties have a type key in the descriptor that accepts a type or string representing a type:

Object.defineProperty(o, 'a', { type: uint8 }); // using the type
Object.defineProperty(o, 'b', { type: 'uint8' }); // using a string representing the type

Object.defineProperties(o, {
  'a': {
    type: uint8,
    value: 0,
    writable: true
  },
  'b': {
    type: string,
    value: 'a',
    writable: true
  }
});

The type information is also available in the property descriptor accessed with Object.getOwnPropertyDescriptor or Object.getOwnPropertyDescriptors:

const o = { a: uint8 };
const descriptor = Object.getOwnPropertyDescriptor(o, 'a');
descriptor.type; // uint8

const descriptors = Object.getOwnPropertyDescriptors(o);
descriptors.a.type; // uint8

Note that the type key in the descriptor is the actual type and not a string.

The key value for a property with a numeric type defined in this spec defaults to 0. This modifies the behavior that currently says that value is defaulted to undefined. It will still be undefined if no type is set in the descriptor. The SIMD types also default to 0 and string defaults to an empty string.

Class: Value Type and Reference Type Behavior

Any class where at least one public and private field is typed is automatically sealed. (As if Object.seal was called on it). A frozen Object prototype is used as well preventing any modification except writing to fields.

If every field is typed with a value type then instances can be treated like a value type in arrays. The class also inherits from SharedArrayBuffer allowing instances or arrays to be shared among web workers.

class A { // can be treated like a value type
  a: uint8;
  #b: uint8;
}
class B extends A { // can be treated like a value type
  a: uint16;
}
class C { // cannot be treated like a value type
  a: uint8;
  b;
}

The value type behavior is used when creating sequential data in typed arrays.

const a: [10].<A>; // creates an array of 10 items with sequential data
a[0] = 10;
const b: [10].<A>|null; // reference
b = a;
b[0]; // 10

This is identical to allocating an array of 20 bytes that looks like a, #b, a, #b, ....

An array view can be created over this sequential memory to view as something else. Since this applies to all typed arrays, value type class array views can also be applied over contiguous bytes to create more readable code when parsing binary formats.

class HeaderSection {
  a: uint8;
  b: uint32;
}
class Header {
  a: uint8;
  b: uint16;
  c: HeaderSection;
}
const buffer: [100].<uint8>; // Pretend this has data
const header = ref [].<Header>(buffer)[0]; // Create a view over the bytes using the [].<Header> and get the first element
header.c.a = 10;
buffer[3]; // 10

When using value type classes in typed arrays it's beneficial to be able to reference individual elements. The example above uses this syntax. Refer to the references section on the syntax for this. Attempting to assign a value type to a variable would copy it creating a new instance.

const header = [].<Header>(buffer)[0];
header.c.a = 10;
buffer[3]; // 0

To create arrays of references simply union with null.

const a: [10].<A|null>; // [null, ...]
a[0] = new A();

To change a class to be unsealed when its fields are typed use the dynamic keyword. This stops the class from being used for sequential data as well, so it cannot become a value type in typed arrays.

dynamic class A {
  a: uint8;
  #b: uint8;
}
const a: [10].<A>; // [A, ...]
const b: [10].<A|null>; // [null, ...]

Constructor Overloading

class MyType {
  x: float32; // Able to define members outside of the constructor
  constructor(x: float32) {
    this.x = x;
  }
  constructor(y: uint32) {
    this.x = (y as float32) * 2;
  }
}

Implicit casting using the constructors:

let t: MyType = 1; // float32 constructor call
let t: MyType = 1 as uint32; // uint32 constructor called

Constructing arrays all of the same type:

let t = new [5].<MyType>(1);

parseFloat and parseInt For Each New Type

For integers (including bigint) the parse function would have the signature parse(string, radix = 10).

let a: uint8 = uint8.parse('1', 10);
let b: uint8 = uint8.parse('1'); // Same as the above with a default 10 for radix
let c: uint8 = '1'; // Calls parse automatically making it identical to the above

For floats, decimals, and rational the signature is just parse(string).

let a: float32 = float32.parse('1.2');

TODO: Define the expected inputs allowed. (See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseFloat). Also should a failure throw or return NaN if the type supports it. I'm leaning toward throwing in all cases where erroneous values are parsed. It's usually not in the program's design that NaN is an expected value and parsing to NaN just created hidden bugs.

Implicit SIMD Constructors

Going from a scalar to a vector:

let a: float32x4 = 1; // Equivalent to let a = float32x4(1, 1, 1, 1);

Classes and Operator Overloading

A compact syntax is proposed with signatures. These can be overloaded to work with various types. Note that the unary operators have no parameters which differentiates them from the binary operators.

See this for more examples: https://github.com/tc39/proposal-operator-overloading/issues/29

class A {
  operator+=(rhs) {}
  operator-=(rhs) {}
  operator*=(rhs) {}
  operator/=(rhs) {}
  operator%=(rhs) {}
  operator**=(rhs) {}
  operator<<=(rhs) {}
  operator>>=(rhs) {}
  operator>>>=(rhs) {}
  operator&=(rhs) {}
  operator^=(rhs) {}
  operator|=(rhs) {}
  operator+(rhs) {}
  operator-(rhs) {}
  operator*(rhs) {}
  operator/(rhs) {}
  operator%(rhs) {}
  operator**(rhs) {}
  operator<<(rhs) {}
  operator>>(rhs) {}
  operator>>>(rhs) {}
  operator&(rhs) {}
  operator|(rhs) {}
  operator^(rhs) {}
  operator~() {}
  operator==(rhs) {}
  operator!=(rhs) {}
  operator<(rhs) {}
  operator<=(rhs) {}
  operator>(rhs) {}
  operator>=(rhs) {}
  operator&&(rhs) {}
  operator||(rhs) {}
  operator!() {}
  operator++() {} // prefix (++a)
  operator++(nothing) {} // postfix (a++)
  operator--() {} // prefix (--a)
  operator--(nothing) {} // postfix (a--)
  operator-() {}
  operator+() {}
  get operator[]() {}
  set operator[](...args, value) {}
  operator T() {} // Implicit cast operator
}

Examples:

class Vector2 {
  x: float32;
  y: float32;
  constructor(x: float32 = 0, y: float32 = 0) {
    this.x = x;
    this.y = y;
  }
  length(): float32 {
    return Math.hypot(this.x, this.y); // uses Math.hypot(...:float32):float32 due to input and return type
  }
  operator+(v: Vector2): Vector2 { // Same as [Symbol.addition](v:Vector2)
    return new vector2(this.x + v.x, this.y + v.y);
  }
  operator==(v: Vector2): boolean {
    const epsilon = 0.0001;
    return Math.abs(this.x - v.x) < epsilon && Math.abs(this.y - v.y) < epsilon;
  }
}

const a = new Vector2(1, 0);
const b = new Vector2(2, 0);
const c = a + b;
c.x; // 3

Again this might not be viable syntax as it dynamically adds an operator and would incur performance issues:

var a = { b: 0 };
a[Symbol.additionAssignment] = function(value) {
  this.b += value;
};
a += 5;
a.b; // 5

Static Operator Overloading

Classes can also implement static operator overloading.

class A {
  static x = 0;
  static operator+=(value) {
    this.x += value;
  }
}
A += 5; // A.x is 5

This is kind of niche, but it's consistent with other method definitions, so it's included.

Class Extension

Example defined in say MyClass.js defining extensions to Vector2 defined above:

class Vector2 {
  operator==(v: MyClass) {
    // equality check between this and MyClass
  }
  operator+(v: MyClass) {
    return v + this; // defined in terms of the MyClass operator
  }
}

Note that no members may be defined in an extension class. The new methods are simply appended to the existing class definition.

SIMD Operators

All SIMD types would have operator overloading added when used with the same type.

let a = uint32x4(1, 2, 3, 4) + uint32x4(5, 6, 7, 8); // uint32x4
let b = uint32x4(1, 2, 3, 4) < uint32x4(5, 6, 7, 8); // boolean32x4

It's also possible to overload class operators to work with them, but the optimizations would be implementation specific if they result in SIMD instructions.

enum Type

Enumerations with enum that support any type including functions and symbols.

enum Count { Zero, One, Two }; // Starts at 0
let c: Count = Count.Zero;

enum Count { One = 1, Two, Three }; // Two is 2 since these are sequential
let c: Count = Count.One;

enum Count: float32 { Zero, One, Two };

enum Counter: (float32) => float32 { Zero = x => 0, One = x => x + 1, Two = x => x + 2 }

Custom sequential functions for types can be used. (Note these aren't closures):

enum Count: float32 { Zero = (index, name) => index * 100, One, Two }; // 0, 100, 200
enum Count: string { Zero = (index, name) => name, One, Two = (index, name) => name.toLowerCase(), Three }; // "Zero", "One", "two", "three"
enum Flags: uint32 { None = 0, Flag1 = (index, name) => 1 << (index - 1), Flag2, Flag3 } // 0, 1, 2, 4

An enumeration that uses a non-numeric type must define a starting value. If a sequential function or an overloaded assignment operator is not found the next value will be equal to the previous value.

// enum Count:string { Zero, One, Two }; // TypeError Zero is undefined, expected string
enum Count:string { Zero = '0', One, Two }; // One and Two are also '0' because string has no prefix increment operator

class A {
  constructor(value) {
    this.value = value;
  }
  operator+(value: number) { // prefix increment
    return new A(this.value + value);
  }
}
enum ExampleA: A { Zero = new A(0), One, Two }; // One = new A(0) + 1, Two = One + 1 using the addition operator.

Index operator:

enum Count { Zero, One, Two };
Count[0]; // Count.Zero
Count['Zero']; // Count.Zero

Get enum value as string:

Count.toString(Count.Zero); // 'Zero'

It seems like there needs to be an expression form also. Something akin to Function or GeneratorFunction which allows the construction of features with strings. It's not clear to me if this is required or beneficial, but it could be. I guess the syntax would look like:

new enum('a', 0, 'b', 1);
new enum(':uint8', 'a', 0, 'b', 1);
new enum(':string', 'None', 'none', 'Flag1', '(index, name) => name', 'Flag2', 'Flag3'); // This doesn't make much sense though since the value pairing is broken. Need a different syntax

Similar to Array there would be a number of reserved functions:

enum.prototype.keys() // Array Iterator with the string keys
enum.prototype.values() // Array Iterator with the values
enum.prototype.entries() // Array Iterator with [key, value]
enum.prototype.forEach((key, value, enumeration) => {})
enum.prototype.filter((key, value, enumeration) => {}) // returns an Array
enum.prototype.map((key, value, enumeration) => {}) // returns an Array
enum.prototype[@@iterator]()

Iteration would work like this:

enum Count { Zero, One, Two };

for (const [key, value] of Count) {
  // key = 'Zero', value = 0
}

Enum values can reference previous values:

enum E { A = 0, B = A + 5 };

Named Parameters

Named parameters are a compact way to skip default parameters.

function f(a: uint8, b: string = 0, ...args: string) {}
f(8, args: 'a', 'b');

function g(option1: string, option2: string) {}
g(option2: 'a'); // TypeError no signature for G matches (option2: string)

Spread operator on an object will implement an iterable:

function f(a: uint32, b: string) {}
f(...{ a: 10, b: 'b' });

TODO: Syntax for adding parameters using spread?

interface Config {
  name: string,
  min: uint32,
  max: uint32
}

function f(...{ ...Config }) {
  console.log(name, min, max);
}

TODO: Does this work with intersection and union types?

type FloatType = { type: 'float', min: float32, max: float32 };
type IntType = { type: 'int', min: int32, max: int32 };
type Shared = { label: string };
type Mixed = (FloatType | IntType) & Shared;

function f(...Mixed: mixed) {
  // Do something with label
  // ...
  match (mixed) {
    FloatType: // float handling
    IntType: // int handling
  }
}

Rest Parameters

function f(a: string, ...args: [].<uint32>) {}
f('a', 0, 1, 2, 3);

Rest parameters are valid for signatures:

let a:(...: [].<uint8>);

Multiple rest parameters can be used:

function f(a: string, ...args: [].<uint32>, ...args2: [].<string>, callback: ()) {}
f('a', 0, 1, 2, 'a', 'b', () => {});

Dynamic types have less precedence than typed parameters:

function f(...args1, callback: (), ...args2, callback: ()) {}
f('a', 1, 1.0, () => {}, 'b', 2, 2.0, () => {});

Rest array destructuring:

function f(...[a: uint8, b: uint8, c: uint8]) {
  return a + b + c;
}

The behavior of rest parameters can create confusing signatures. While these are allowed, they aren't recommedned. Arguments are taken by parameters greedily and given back to satisfy signatures.

function f(...a: [].<uint32>, ...b: [].<uint32>, c: uint32): void {}
f(0, 1, 2); // a: [0, 1], b: [], c: 2
f(a: 0, 1, 2, b: 3, 4, 5, 6); // a: [0, 1, 2], b: [3, 4, 5], c: 6

Try Catch

Catch clauses can be typed allowing for minimal conditional catch clauses.

try {
  // Statement that throws
} catch (e: TypeError) {
  // Statements to handle TypeError exceptions
} catch (e: RangeError) {
  // Statements to handle RangeError exceptions
} catch (e: EvalError) {
  // Statements to handle EvalError exceptions
} catch (e) {
  // Statements to handle any unspecified exceptions
}

Placement New

Arbitrary arrays can be allocated into using the placement new syntax. This works with both a single instance and array of instances.

Single instance syntax:

// new(buffer [, byteOffset]) Type()
let a = new(buffer, byteOffset) Type(0);

Array of instances syntax:

// new(buffer [, byteOffset [, byteElementLength]]) [n].<Type>()
let a = new(buffer, byteOffset, byteElementLength) [10].<Type>(0);

By default byteElementLength is the size of the type. Using a larger value than the size of the type acts as a stride adding padding between allocations in the buffer. Using a smaller length is unusual as it causes allocations to overlap.

Value Type References

https://github.com/rbuckton/proposal-refs

The only difference with the above is that reference objects have operator overloading so there's no exposed value.

function f(ref a: int32) {
  a++;
}
let a = 0;
f(ref a);
a; // 1

If a property is in an object this can also be concise:

const o = { a: 0 };
f(ref o.a);
o.a; // 1

Destructuring syntax supports references as well:

function f({ (ref a: int32) }) {
 a++;
}
const o = { a: 0 };
f(ref o);
o.a; // 1

References can also be used to refer to elements in value type arrays.

const a: [].<int32>;
let b = ref a[0];
b = 10;
a[0]; // 10

This works on value type classes described in another section.

class A {
  a:uint32;
  b:uint32;
}
const a: [10].<A>;
const b = ref a[0];
b.a = 10;

function f(ref c: A) {
  c.a = 10;
}
f(ref a[1]);

Functions can return a reference to an array value as well.

function f(a): int32 {
  return ref a[0];
}
const a: [10].<int32>;
f(a)++; // This is new syntax where the post-increment operates immediately on the returned value
a[0]; // 1
let ref b = f(a);
b = 10;
a[0]; // 10

Reassigning a reference is allowed also:

const a: [10].<int32>;
let ref b = a[0];
ref b = a[1];

Control Structures

if else

A table should be included here with every type and which values evaluate to executing. At first glance it might just be 0 and NaN do not execute and all other values do. SIMD types probably would not implicitly cast to boolean and attempting to would produce a TypeError indicating no implicit cast is available.

switch

The variable when typed in a switch statement must be integral, string, or symbol type. Specifically int8/16/32/64, uint8/16/32/64, number, and string. Most languages do not allow floating point case statements unless they also support ranges. (This could be considered later without causing backwards compatability issues).

Enumerations can be used dependent on if their type is integral or string.

let a: uint32 = 10;
switch (a) {
  case 10:
    break;
  case 'baz': // TypeError unexpected string literal, expected uint32 literal
    break;
}

let a: float32 = 1.23;
//switch (a) { // TypeError float32 is not a valid type for switch expression
//}

Member memory alignment and offset

By default the memory layout of a typed class - a class where every property is typed - simply appends to the memory of the extended class. For example:

class A {
    a: uint8;
}
class B extends A {
    b: uint8;
}
// So the memory layout would be the same as:
class AB {
    a: uint8;
    b: uint8;
}

Two new keys would be added to the property descriptor called align and offset. For consistency between codebases two reserved decorators would be created called @align and @offset that would set the underlying keys with byte values. Align defines the memory address to be a multiple of a given number. (On some software architectures specialized move operations and cache boundaries can use these for small advantages). Offset is always defined as the number of bytes from the start of the class allocation in memory. (The offset starts at 0 for each class. Negative offset values can be used to overlap the memory of base classes). It's possible to create a union by defining overlapping offsets.

Along with the member decorators, two object reserved descriptor keys would be created, alignAll and size. These would control the allocated memory alignment of the instances and the allocated size of the instances.

WIP: Need byte and bit versions of these alignment features.

@alignAll(16) // Defines the class memory alignment to be 16 byte aligned
@size(32) // Defines the class as 32 bytes. Pads with zeros when allocating
class A {
  @offset(2)
  x: float32; // Aligned to 16 bytes because of the class alignment and offset by 2 bytes because of the property alignment
  @align(4)
  y: float32x4; // 2 (from the offset above) + 4 (for x) is 6 bytes and we said it has to be aligned to 4 bytes so 8 bytes offset from the start of the allocation. Instead of @align(4) we could have put @offset(8)
}

The following is an example of overlapping properties using offset creating a union where both properties map to the same memory. Notice the use of a negative offset to reach into a base class memory.

class A {
  a: uint8;
}
class B extends A {
  @offset(-1)
  b: uint8;
}
// So the memory layout would be the same as:
class AB { // size is 1 byte
  a: uint8;
  @offset(0)
  b: uint8;
}
const ab = new AB();
ab.a = 10;
ab.b == 10; // true

These descriptor features only apply if all the properties in a class are typed along with the complete prototype chain.

WIP: Adding properties later with Object.defineProperty is only allowed on dynamic class instances.

class A {
  a: uint8;
  constructor(a:uint8) {
    this.a = a;
  }
}
const a:[].<A> = [0, 1, 2];

Object.defineProperty(A, 'b', {
  value: 0,
  writable: true,
  type: uint8
});
const b:[].<A> = [0, 1, 2];

// a[0].b // TypeError: Undefined property b
b[0].b; // 0

Global Objects

The following global objects could be used as types:

DataView, Date, Error, EvalError, InternalError, Map, Promise, Proxy, RangeError, ReferenceError, RegExp, Set, SyntaxError, TypeError, URIError, WeakMap, WeakSet

Generics

Generics

Decorators

Decorators

Records and Tuples

https://github.com/sirisian/ecmascript-types/issues/56

Types would work as expected with Records and Tuples:

interface IPoint { x: int32, y: int32 }
const ship1:IPoint = #{ x: 1, y: 2 };
// ship2 is an ordinary object:
const ship2:IPoint = { x: -1, y: 3 };

function move(start: IPoint, deltaX: int32, deltaY: int32): IPoint {
  // we always return a record after moving
  return #{
    x: start.x + deltaX,
    y: start.y + deltaY,
  };
}

const ship1Moved = move(ship1, 1, 0);
// passing an ordinary object to move() still works:
const ship2Moved = move(ship2, 3, -1);

console.log(ship1Moved === ship2Moved); // true
// ship1 and ship2 have the same coordinates after moving

const measures = #[uint8(42), uint8(12), uint8(67), "measure error: foo happened"];

// Accessing indices like you would with arrays!
console.log(measures[0]); // 42
console.log(measures[3]); // measure error: foo happened

// Slice and spread like arrays!
const correctedMeasures = #[
  ...measures.slice(0, measures.length - 1),
  int32(-1)
];
console.log(correctedMeasures[0]); // 42
console.log(correctedMeasures[3]); // -1

// or use the .with() shorthand for the same result:
const correctedMeasures2 = measures.with(3, -1);
console.log(correctedMeasures2[0]); // 42
console.log(correctedMeasures2[3]); // -1

// Tuples support methods similar to Arrays
console.log(correctedMeasures2.map(x => x + 1)); // #[43, 13, 68, 0]

Undecided Topics

Import Types

This has been brought up before, but possible solutions due to compatability issues would be to introduce special imports. Brenden once suggested something like:

import {int8, int16, int32, int64} from "@valueobjects";
//import "@valueobjects";

Overview of Future Considerations and Concerns

Partial Class

partial class MyType {
}

Partial classes are when you define a single class into multiple pieces. When using partial classes the ordering members would be undefined. What this means is you cannot create views of a partial class using the normal array syntax and this would throw an error.

Switch ranges

If case ranges were added and switches were allowed to use non-integral and non-string types then the following syntax could be used in future proposals without conflicting since this proposal would throw a TypeError restricting all cases of its usage keeping the behavior open for later ideas.

let a:float32 = 1 / 5;
switch (a) {
  case 0..0.99:
    break;
}

Bit-fields

These are incredibly niche. That said I've had at least one person mention them to me in an issue. C itself has many rules like that property order is undefined allowing properties to be rearranged more optimally meaning the memory layout isn't defined. This would all have to be defined probably since some view this as a benefit and others view it as a design problem. Controlling options with decorators might be ideal. Packing and other rules would also need to be clearly defined.

class Vector2 {
  x: uint.<4>; // 4 bits
  @offsetBit(4)
  y: uint.<4>; // 4 bits
}

Exception filters

See https://github.com/sirisian/ecmascript-types/issues/22

A very compact syntax can be used later for exception filters:

catch (e: Error => e.message == 'a')

Or

catch (e: Error => console.log(e.message))

This accomplishes exception filters without requiring a keyword like "when". That said it would probably not be a true lambda and instead be limited to only expressions.

Threading

Threading

Example:

Packet bit writer/reader https://gist.github.com/sirisian/dbc628dde19771b54dec

Previous discussions

Current Mailing List Thread: https://esdiscuss.org/topic/proposal-optional-static-typing-part-3

Second Thread: https://esdiscuss.org/topic/optional-static-typing-part-2
Original thread: https://esdiscuss.org/topic/es8-proposal-optional-static-typing
This one contains a lot of my old thoughts: https://esdiscuss.org/topic/proposal-for-new-floating-point-and-integer-data-types
https://esdiscuss.org/topic/optional-strong-typing
https://esdiscuss.org/topic/optional-argument-types