Ideas on type hinting and named parameters

Thaddee Tyl thaddee.tyl at gmail.com
Tue Jun 9 08:21:59 UTC 2015


I like that syntax.

I wonder about the runtime semantics of it, though. (I know TypeHint
is a TODO, but…)
Is there any implication at runtime of a function that returns a String?
Is this:

```js
var point = {
  x Number,
  y Number
};
```

… the same as this?

```js
var point = {
  x: Number(),
  y: Number()
};
```

In which case we would need rules for constructors to always have
default parameters, right?

If those annotations are all only for a non-runtime type check, I feel
strange now about having type analysis only for newly defined symbols.
Since this is meant as some kind of pre-runtime `assert(symbol
instanceof Type)`, we might want to check:
- field types (such as `foo {bar Number}`)
- parameter types (such as `Array[Number]` or `Map[String, Array[String]]`)
- function types (such as `function(String) Number`)
- union types (such as `RegExp | null`)
- generics, possibly with extends / superclass (such as
`function(items Array[T extends Entity], unmap function(Number) T)`)?

Could we typedef types? Could we define covariance and contravariance
rules in new types with generics?

On a side-note, we can actually track the full list of methods used
for each parameter, and check that each function call respects them.
Maybe type inference has been researched enough that we can now use
better tools that need no type hints.


More information about the es-discuss mailing list