Improve error reporting: Smarter heuristics on incorrect return type of if / else branch

[isaacabraham]

What

If types are incompatible across all branches of an if / else expression, the return type of the first branch is used to determine the "correct" type. Given the following code sample, this behaviour, whilst consistent, is usually not what the user expects: -

let test = 10
let y =
    if test > 10 then "test"
    elif test > 20 then 456
    elif test > 30 then 789
    elif test > 35 then 101010
    else 123

error FS0001: This expression was expected to have type string but here has type int

In this case, all four branches that return an integer are flagged as having an error when it is much more likely that the first branch ("test") is in error.

Why

Changing the first type in a conditional causes all the other cases to break, when in fact it's normally the first one that's in error. A beginner will follow all the error messages raised by the compiler and not realise that they are actually all correct, but in fact the error is located in the one branch that the compiler has not flagged.

How

The compiler should ideally find the most "common" return type and flag that as the correct one and mark the other branch(es) as being in error.

[smoothdeveloper]

Maybe the compiler should list the several types:

error FS0001: The expressions are of inconsistent type: string 1 occurence(s), int 4 occurence(s). Make expression type consistent across all the branches

verbose output can also contain this:

if test > 10 then "test"
__________________^ string
elif test > 20 then 456
____________________^ int
elif test > 30 then 789
____________________^ int
elif test > 35 then 101010
____________________^ int
else 123
_____^ int

[lulu-berlin]

Similarly to here, I'd like to suggest something like: The types of the values produced in all "then" and "else" branches of a conditional expression must match.

[isaacabraham]

I think we can do better than that; just saying they must all match is good, but telling the user what the current branches are and what one should be changed is better.

[lulu-berlin]

Trying again: The types of the values produced in all "then" (string, int, int, int) and "else" (int) branches of a conditional expression are expected to match. Make expression type consistent across all branches

[isaacabraham]

See my comment in the other issue - splitting up by "then" and "else" doesn't (IMHO) make much sense. Easier just to say "all branches (string, int)" etc. I think?

[lulu-berlin]

@isaacabraham, I agree - but as I commented on #1105, I think it makes sense to mention the existence of the "then" and "else" branches without spliting the type listing.

[forki]

#1142 already gives:

I think this is already pretty good.

[forki]

A little background: the type checker is adding type unification formulas basically expression by expression. The first formula that introduces a conflict will be reported. At this point we don't have enough TAST information to make assumptions about the other branches. I vote to close this specific request since the error message is already better than before and I don't see a way to improve that as described here without changing the design of the type checker.

[dsyme]

Yes, it's very hard to vote across the different branches. I will close this specific suggestion.

[isaacabraham]

I suspected that this would be the case - it's good that we've looked into this though and understand why it's not appropriate. Perhaps this can be revisited another time :-)