-
-
Notifications
You must be signed in to change notification settings - Fork 5.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
Function specialization for tuple arguments? #4090
Comments
For now a workaround for this is to use a static parameter:
This will force specialization. The problem with tuple types is that there are too many of them ( |
I wondered if combinatorial explosion was the issue. Your tip was a huge help, many thanks. |
I ran into this today, and I can't help but wonder if this behavior could be refined. Consider: julia> f(x) = length(x) == 1 ? x[1] : x;
julia> g() = f((1, 2));
julia> g()
(1,2) It seems like we perform type inference for |
@JeffBezanson your paper states that the heuristic is "[to] avoid specializing methods for tuple types of every length". Does this mean that specializations are indeed generated for prefixes of the tuple of types up to some fixed limit k? |
Functions receiving a tuple argument do not appear to be specialized for the tuple-of-types:
Benchmark (after one run to compile):
Not sure whether this is a TODO, a bug, or a deliberate design decision, but I thought it was worth bringing to attention.
Interestingly, this doesn't apply for a type defined by a tuple-of-types:
One place this comes up in practice if you write a
copy!
function to work between two regions of two arrays, e.g.,copy!(dest::Array, destindexes, src::Array, srcindexes)
. In such cases you lose information if you try to write it with...
notation.The text was updated successfully, but these errors were encountered: