The question here is that a type inference can assign type to a hole but may get confused if user insists on an incompatible type.
int q
// q is considered a hole of int type
q <-
// but we're typing "hello" there
Practicalities ask for the situation to be considered a problem - not of incorrectly plugged hole (when into "int" place you're putting "string" value), but of incorrectly previously stated type (it's the original "int q" which is wrong, should have been "string q").
int q // q is considered a hole of int type
q <- // but we're typing "hello" there
Practicalities ask for the situation to be considered a problem - not of incorrectly plugged hole (when into "int" place you're putting "string" value), but of incorrectly previously stated type (it's the original "int q" which is wrong, should have been "string q").