-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Demotion to const ptr leads to confusing error message #2949
Comments
Basically what would have to happen, I think, is that the inference engine remembers all types that influenced the final result and prints them out. |
Maybe stratify checking on assignments and dereferences? Really the error you want to see is "assignment to x of wrong type". |
This is sort of an unsolvable problem. We don't want to say that the type of a variable is precisely equal to its first assignment. Imagine, for example, that we implement the "case class" proposal and therefore
would be illegal. But at the same time there are a series of conflicting constraints. Right now we take the ML approach and print a message at the point we detect the inconsistency. This is probably fine, but where we go wrong is that we (like every other type-inferring language I've used) choose to blame the point where we detected the inconsistency, when really the incorrect statement could be any of the statements that contribute. So probably the best we can do is identify the contradictory constraints and the statements which led to them, and let the user decide which one is wrong. |
To put it another way, if there were no |
Updated test case
|
I have been wanting to do an experiment of switching to a standard unification-based inference scheme rather than the current one which tries to reason about subtyping. This will be a mixed bag, because the current one handles some cases correctly, but it would also solve this particular problem. |
Still relevant |
Triage: |
cronjob auto-PR: fetch more of the history
gives me a somewhat confusing error
Took me a while to figure out that the last assignment was forcing x to become a const ptr for its entire life. That was my mistake, but causing an error earlier in the function threw me off. It would be nice if the compiler explained why the type of x was not what it appeared to be.
The text was updated successfully, but these errors were encountered: