I thought I understood the where syntax but apparently I don’t. I have a parameterised structure along the lines of
struct MyStruct{T <: Number, F}
u::Vector{T}
f::F
end
and I’d like to have a vector of these structures such that the underlying numerical type is the same but the f field can be different (it’s a function). For example
In this case, as I understand it, the appropriate type signature is Vector{MyStruct{T, F} where F} where T and, as desired,
v isa Vector{MyStruct{T, F} where F} where T == true
However, if I just have a single element in the vector
vv = [v1]
vv isa Vector{MyStruct{T, F} where F} where T == false
but I don’t understand why.
I’d like to be able to handle both these cases. Is there a type signature that can handle both? (I know I can use a union with Vector{MyStruct{T, F}} where {T, F} but I was expecting the where syntax to be able to handle this directly.)
A Vector{MyStruct{T, F} where F} where T has an element type which allows potentially different Fs for each element. When you do [v1] you’re instead getting Vector{MyStruct{Float64, typeof(sin)}} which has an element type which allows only that exact type. Those two Vector types are actually different types in Julia (because they have different element types).
Instead, you probably want, roughly, “A vector whose element type is some subtype of MyStruct{T, F} where F”. You can write that as:
Vector{M} where {T, M <: (MyStruct{T, F} where F)}
or, more simply, since you can leave off trailing type parameters:
Yup, it will actually be better. ::Function is an abstract type, so access to the f field would be type-unstable in that case. Of course, this may not actually matter much, depending on how that field is used, so it’s always worth benchmarking to be sure.
In this case it’s going to be in a hot loop where performance is critical hence going for the parameterized form. (Though by the time it hits the hot loop it’s also been unpacked into a tuple with some @generated magic to avoid dynamic dispatch entirely. The vector form is for user convenience as the problem is sequentially constructed.)
Also, I quite like the convenience of being able to use arbitrary callables (e.g. callable structs), which aren’t subtypes of Function, as well as regular functions.