-
-
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
Avoid unnecessary conversions of nullables. #12424
Conversation
954246f
to
a4c0707
Compare
Looks like a good idea to me. CC: @johnmyleswhite |
I'd have thought that convert{T}(::T, x::T) = x Was always true, and would have been defined somewhere earlier for some reason. I guess this is actually more like convert{T,S}(::T{S}, x::T{S}) = x or something though? 😕 |
I think there should be an ambiguity warning for this julia> f{T}(::Type{T}, x::T) = 1
f (generic function with 1 method)
julia> f{T}(::Type{Nullable{T}}, x::Nullable) = 2
f (generic function with 2 methods) Only the first one can match |
Yikes, Nullable certainly isn't the only type that affected by this. Should I add more Edit: Ok so it's not that bad. Non-exhaustively, these types all have this issue: |
LGTM |
Just to clarify for myself: is the reason we can't have |
@johnmyleswhite My understanding of the specific/ambigious is that if it is possible to match A without matching B, then A is not more specific than B. If both A and B match something but none of them is more specific than the other, then the two are ambigious. With this definition, I think there's a missing ambiguity warning here #12424 (comment) |
There's a bigger problem here, but this certainly seems correct in any case. |
Avoid unnecessary conversions of nullables.
There's currently an unnecessary conversion that happens between nullables of the same type. Adding this def sped up some code I was working by 2x.
Here's a contrived benchmark
Before this PR:
0.409873 seconds (155 allocations: 10.543 KB)
After this PR:
0.070780 seconds (155 allocations: 10.543 KB)