You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Indicate expected versus actual types in type errors #3399
I never know what the compiler wants from me when it says:
Could not match type A with type B
Which one does it expect? Which one is the one I supply?
For people like me it's not always obvious which type I am supplying.
I don't really see any downside to changing this to:
Could not match expected type A with actual type B
I don't know about any tooling that might depend on this exact message.
I think it could be even nicer if the compiler could insert a little (?helpme (thingOfTheWrongType)) and suggest possible fixes but that's most probably out of scope.
We've had issues about this previously, and did attempt to change the error to work this way... but unfortunately the type checker isn't able to know for sure whether A or B is the type that is actually desired.
Actually maybe we could make that explicit in the message? I remember trying to find the order by making some minimal example. Since there is no order this could be misleading. I know there is nothing in the message suggests that there is an order but still. The message could have a little "in no particular order" disclaimer.
Actually sorry, I take back what I said before: while we do have discussion which notes that identifying expected vs actual types would be useful, there doesn’t appear to be an open issue for actually doing so.
I wrote this on discord, but thought I would add it as a suggestion here as well -
Looking at the error message in this issue #1577 - Some very useful information is partly present but buried - "checking that expression 4 has type String". Is it possible to put that information up front?
For example the error messages could say something like -
Error occurred while checking that
expression
4
has type
String
Could not match type
Int
with type
String
while trying to match type Int
with type String
in value declaration foo
Activity
i-am-the-slime commentedon Jul 10, 2018
I think it could be even nicer if the compiler could insert a little (?helpme (thingOfTheWrongType)) and suggest possible fixes but that's most probably out of scope.
garyb commentedon Jul 10, 2018
We've had issues about this previously, and did attempt to change the error to work this way... but unfortunately the type checker isn't able to know for sure whether A or B is the type that is actually desired.
hdgarrood commentedon Jul 11, 2018
Yeah, I’m certain there is already an issue for exactly this, possibly even open.
i-am-the-slime commentedon Jul 12, 2018
I see. Sorry guys!
i-am-the-slime commentedon Jul 12, 2018
Actually maybe we could make that explicit in the message? I remember trying to find the order by making some minimal example. Since there is no order this could be misleading. I know there is nothing in the message suggests that there is an order but still. The message could have a little "in no particular order" disclaimer.
hdgarrood commentedon Jul 13, 2018
Previously: #3111 #1577 #1583
hdgarrood commentedon Jul 13, 2018
Actually sorry, I take back what I said before: while we do have discussion which notes that identifying expected vs actual types would be useful, there doesn’t appear to be an open issue for actually doing so.
hdgarrood commentedon Jul 13, 2018
So we might want to reopen this perhaps?
JordanMartinez commentedon Nov 27, 2018
I think this should be reopened. At the very least, it would track that the issue does exist.
[-]Improve error message for non-matching types[/-][+]Indicate expected versus actual types in type errors[/+]ajnsit commentedon Aug 19, 2021
I wrote this on discord, but thought I would add it as a suggestion here as well -
Looking at the error message in this issue #1577 - Some very useful information is partly present but buried - "checking that expression 4 has type String". Is it possible to put that information up front?
For example the error messages could say something like -