[com2kid]

Ecmascript 4 was an attempt to add better types to the language, which sadly failed a long time ago.

It'd be nice of TS at least allowed for specifying types like integer, allowing some of the newer TS aware runtimes could take advantage of the additional info, even if the main TS->JS compilation just treated `const val: int` the same as `const val: number`.

I wonder if a syntax like

    const counter: Number<int>

would be acceptable.

[the_imp]

With Extractors [1] (currently at Stage 1), you could define something like this to work:

    const Integer = {
      [Symbol.customMatcher]: (value) => [Number.parseInt(value)]
    }

    const Integer(counter) = 42.56;
    // counter === 42

[1] https://github.com/tc39/proposal-extractors

[THBC]

Number is not semantically compatible with raw 64-bit integer, so you might as well wish for a native

    const counter = UInt64(42);

The current state of the art is

    const counter = BigInt.asUintN(64, 42);

[obviouslynotme]

Yeah, that is why I said TS (or something similar). TS made some decisions that make sense at the time, but do not help compilation. The complexity of its typing system is another problem. I'm pretty sure that it is Turing-complete. That doesn't remove feasibility, but it increases the complexity of compiling it by a whole lot. When you add onto this the fact that "the compiler is the spec," you really get bogged down. It would be much easier to recognize a sensible subset of TS. You could probably even have the type checker throw a WTFisThisGuyDoing flag and just immediately downgrade it to an any.

[com2kid]

> I'm pretty sure that it is Turing-complete.

Because JS code can arbitrarily modify a type, any language trying to specify what the outputs of a function can be also has to be Turing complete.

There are of course still plenty of types that TS doesn't bother trying to model, but it does try to cover even funny cases like field names going from kebab-case to camelCase.