-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add line numbers to ambiguity warnings? #1658
Comments
@JeffBezanson: what do you think of the idea of inserting error methods for ambiguities so that they are only a problem if they're used? That would automatically give the line number too :-) |
Line numbers: very good idea and easy to do. Automatic error methods: interesting idea, but depends somewhat on #265 to better handle replacing the method. It might also be too strict to require adding a definition before you can try your code. 99% of the time it's fine if one of the existing methods is called, and at least you can start testing things that way. |
I feel like it's less strict – since most of the time you don't care about the ambiguous case because it never happens. If it does, at least you have an example to figure out how it should be disambiguated. But yes, it probably interacts with #265 (which I've been meaning to talk to you about). |
Stopping your program is not really less strict, but it's a good point that the reason the disambiguating definition doesn't exist is often that you don't intend for it to happen. |
I actually agree that it would help if the existence of ambiguities causes a program-stopping error. I'm sure it's too late to change this, but I personally kind of wish that the most general definitions of functions could come first after then be overwritten by more specific cases, rather than the other way around. That's how humans reason after all (see for example the very long literature in development psychology on language learning). |
I agree with that. It seems like your recent experience with ambiguity warnings indicates that they are quite helpful for improving program design, indicating that maybe we shouldn't do away with them. The idea I had to address this was to give the programmer until the end of file to resolve ambiguities (or in the case of modules, maybe until end of module?), so that you could, within a file, order method definitions arbitrarily without affecting warnings. |
Being able to order methods arbitrarily (even in the case of ambiguity) would be a big win. |
See #270. |
Can we report the line numbers in source code that generate ambiguity warnings? This would make it easier to track them down and fix them.
The text was updated successfully, but these errors were encountered: