-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better error message #2641
Comments
Kind of long! A "pretty" print would be something like i think,
But I haven't come across many of this cases. |
Maybe swapping is enough? |
Pretty printed looks more readable... well regarding the diff it's not the best example of an error that I gave... previous error that I've lost was more interesting - after "not ..." there was a long list of types (on the left as well). I had to copy paste it to editor, break new line on "not..." and go one by one. There was difference with single type entry. Maybe I can reproduce it. I think if you use aliases (sum types / nested) then for some reason it lists types on both sides. I think it shouldn't duplicate types on left hand side and right hand side (splitted by "..., not ..."). |
Btw. is the information about aliases lost at the time when the error is generated? It would be small list if aliases were preserved. |
Ok, got the long error:
Aliases are (more less):
...so it could be less verbose if error message included alias names instead of resolved sum types. |
Having a sort of Levenshtein on type-mismatches and signature matches would be a goldmine error reporting-wise! :-) Most often signature matches (slightly off topic, sorry) consists of an arg being |
I also think @jhass has a point that showing the actual type first and then the possible types would clarify things when the list of possible types is long. The "did you mean" idea sounds fantastic as well. |
This is quite old but the idea to improve these type mismatch error messages is really good. This can be really badly readable, especially when large union types are involved. I'm not sure if swapping actual and expected type would have a real benefit here. I kind of like the order of showing first, what it should be. The reason for the error is that does not match this type. Showing the actual type is more like a hint at what might cause this. Currently, the message format is
or even small union types:
Taking the massive union type from the OP, it would already improve readability very much if there was a line break in between.
It could also help to use slightly different formatting for the types and the text. But still, there is room for improvement. The error message might look like this:
Do you spot the difference? 😄 It's a A simple visual improvement would be to align the leftmost character of both type strings to the same column. This allows to spot different patterns in the text flow and you can easily identify there's a difference in line 4.
Additionally, the error message could just list all the individual types that are not included in the actual type (
|
This kind of compiler errors are hard to parse by humans:
It would be nice to have some kind of diff, maybe
+/-
prefixed lines with single types?The text was updated successfully, but these errors were encountered: