-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Dispatch on tuples of types #10947
Comments
My expectation would be that
|
This seems like a bug. Arguably, it should be possible to use |
I cannot test right now, but what about |
|
Though I'm not clear why
|
Tuples now "infer" their parameters from constructor arguments just like other parametric types do:
The difference is that tuples don't provide a way to request parameter types. If you want, you can construct This is normally what you'd expect, but the corner case is that it's impossible to construct a To do this dispatch, I think you'll have to pass tuple types --- dispatch on |
The difference between Tuple types and Pair is that Tuple types are covariant, specifically so they behave like dispatch. julia> isa(Int, Any)
true
julia> isa(Int, Type{Int})
true
julia> isa(Int, DataType)
true
julia> isa(("",), Tuple{Any})
true
julia> isa(("",), Tuple{String})
true
julia> isa(("",), Tuple{ASCIIString})
true
julia> isa((Int,), Tuple{Any})
true
julia> isa((Int,), Tuple{Type{Int}})
false
julia> isa((Int,), Tuple{DataType})
true Edit: Actually, upon further reflection, I understand now. julia> f(::Tuple{Type{Int}}) = 1
f (generic function with 1 method)
julia> f((Int,))
ERROR: MethodError: `f` has no method matching f(::Tuple{DataType})
Closest candidates are:
f(::Tuple{Type{Int64}}) |
Dispatching on the types works, though it's a bit unsatisfying. The fact that To overcome the breaking change of I have to say in wandering through packages fixing tuple syntax, there seems to be a lot of abuse of tuples where I would have expected named types. Are anonymous tuples used extensively in Julia's base library or compilers? I've always thought that a few tuples here and there were useful internally, but should essentially never be found in public interfaces. |
Yes, it should work to add a method to convert There's nothing wrong with using tuples. In fact now using them is a great idea, since they perform well and don't require declarations. One huge benefit is that if everybody who needs "two integers" uses |
Closing because I don't plan to change anything here. However any further ideas about the future of |
So if |
Tuples are still covariant. One thing worth considering is making |
But if tuples are covariant, then
should imply
(right?) which is clearly not the case currently in 0.4, according to @dcjones original example above. |
I suspect this is perhaps only tangentially related, but it seems a reasonable place to ask. I'm trying to update https://github.com/timholy/HDF5.jl to use the new syntax and am running into problems I can summarize here. Given
Why can I not construct the type as I expect here
I'm hoping this is just a syntax confusion on my part.
But the distinction in this case between the type of the tuple and the tuple itself is confusing for me. I've done one or the other wrong. |
Tim has code which returns a tuple of dimensions. e.g. (10,5,2) for describing fixed-size arrays. Ideally, we'd want to be able to parameterize a type with a tuple of ints, e.g.
It makes me wonder why we can't just have vararg type parameters, e.g. using the (nicer imo!) syntax
|
What you would want is something like |
@toivoh No, that's not what covariance means. @sebastiang |
|
But how do I parameterize a type with a vararg tuple then?
This is conceptually what I want, but I see why it doesn't work:
Of course this doesn't work, because
And this works, but doesn't help me in the least. Where did my
So I'm still confused as to how I can retain the parameterization by a value |
@JeffBezanson, I guess this is what your Really all we want is |
That's right; we've never had
In 0.3 tuples could be types, but |
This is why in HDF5, the wily Tim created a sentinel type
|
@JeffBezanson: You're right, that's not what covariance means. Thinking about it some more, I thought that was what tuple (actually 1-tuple) types mean. Anyway, making
and
equivalent. I have no idea about the implications when it comes to performance, breakage, etc though. |
This may be intentional, but I found it surprising.
Whereas in 0.3
This is in the context of JuliaStats/KernelDensity.jl#14. @sebastiang is trying to dispatch on something that boils down to
foo{T <: A, T <: A}(::Tuple{Type{T}, Type{T}})
but can't figure out how to make in work, nor can I. Am I wrong in expecting it to work?The text was updated successfully, but these errors were encountered: