Type incorrect program doesn't give error (subtyping)

[hesselink]

The following program crashes, but doesn't give a type error:

function g (f: (x: {}) => void): void { f({}) }

function f (x: { foo : { bar }}) { alert(x.foo.bar); }

// Doesn't typecheck
// f({ })

// Typechecks?!
g(f)

I would expect this to give a type error because f expects something with a foo, but g is only going to pass it an empty object.

[DanielRosenwasser]

This is a symptom of bivariance when relating function arguments, which was an intentional design choice taken to support certain JavaScript patterns.

[hesselink]

Ah, that's too bad. Perhaps this could be added to the specification, then? I looked there but couldn't find it.

Are there any plans to make this more strict at some point, perhaps with a flag. While I can see it enables some code to work, in our case it failed to catch bugs that we expected to be caught. We'd rather have to occasional cast than the occasional bug.

[DanielRosenwasser]

Totally understandable. Actually, there is issue #274 which covers just that (i.e. making things more strict).

[hesselink]

Thanks, I'll follow that issue.

The example on the wiki looks almost like the overloading on string values that typescript already allows. Perhaps overloading on enum values could be added as well to support that use case, removing a need for this bivariance?

[DanielRosenwasser]

@RyanCavanaugh recently suggested overloading on enums. I think he might also be able to weigh in here on that question.

[RyanCavanaugh]

Overload on enum is compelling; I think we have an issue for it somewhere? We would probably tackle that after the "string literals as types" proposal as that will set a good foundation for it.

[DanielRosenwasser]

@RyanCavanaugh I can create the issue for it in the mean time.