-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Use unwrapva in MethodError candidates
#42161
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
Conversation
I found an example of a method declaration with an argument
typed as `a::Vararg`, and this triggered an error in showing method
candidates. It's always bad when there's an error triggered when handling
an error. This PR makes the code more robust against such problems.
It's worth noting that this type of method declaration
shouldn't be used: it is better as `a...`. The only time you should
explicitly use `Vararg` is when you are specifying both `T` and
`N` in `Vararg{T,N}`.
Shorter, more readable, and doesn't break Julia. What's not to like? xref JuliaLang/julia#42161
|
@Keno Do we need to keep the undef property for |
I think it's probably fine to normalize inside |
|
Does it appear anywhere else? |
I found an example of a method declaration with an argument
typed as `a::Vararg`, and this triggered an error in showing method
candidates. It's always bad when there's an error triggered when handling
an error. This PR makes the code more robust against such problems.
It's worth noting that this type of method declaration
shouldn't be used: it is better as `a...`. The only time you should
explicitly use `Vararg` is when you are specifying both `T` and
`N` in `Vararg{T,N}`.
I found an example of a method declaration with an argument
typed as `a::Vararg`, and this triggered an error in showing method
candidates. It's always bad when there's an error triggered when handling
an error. This PR makes the code more robust against such problems.
It's worth noting that this type of method declaration
shouldn't be used: it is better as `a...`. The only time you should
explicitly use `Vararg` is when you are specifying both `T` and
`N` in `Vararg{T,N}`.
I found an example of a method declaration with an argument
typed as
a::Vararg, and this triggered an error in showing methodcandidates. It's always bad when there's an error triggered when handling
an error. This PR makes the code more robust against such problems.
It's worth noting that this type of method declaration
shouldn't be used: it is better as
a.... The only time you shouldexplicitly use
Varargis when you are specifying bothTandNinVararg{T,N}.