Goal of the type hinting

[Naddiseo]

To keep the spec shorter and more to the point, a hands off approach to the actual linting/enforcing should be taken. Basically, we define the syntax, but not how it should be interpreted by the engine, or a linter.

Precedents: Python's type hinting Rational and Goals

[Naddiseo]

How much semantic specification do we actually want to make?

[Naddiseo]

What is responsible for the checking?

The KIS approach to this spec would be to copy what mypy and python did: allow an arbitrary, but valid, expression as the hint, then leave it to a library/build tool/linter to do the checking. Of course, if the hinting is kept around afterwards, a la decorators, the engine can also use them if it so chose. Pros:

• Very minimal changes to the spec
• Precedent with mypy

Cons:

• Slightly more verbose syntax for compound types
• Possible loss of information for the engine.
• If the expressions have side effects, might have strange behaviour
• No clear separation between compile-time and run-time code.

[lukescott]

Arbitrary, not meaning "any expression", but a single variable reference, I'm assuming. If that's the case static analysis should work. Flow does this. Although I'm not sure you can catch everything, so having runtime checking may be beneficial.

[Naddiseo]

There are a couple options we can explore.

1. Run-time only
2. Compile time only
3. Run-time with optional Compile time
4. Compile time with optional Run-time
5. Optional Compile and Run time

I'll flesh this thought out tomorrow; I have to get up in 6 hours.