Rework wrapper type #23
Conversation
Prevent converting e.g. Base.OneTo to an array.
| # https://github.com/JuliaLang/julia/pull/31563 | ||
|
|
||
| # accessors for extracting information about the wrapper type | ||
| Base.ndims(::Type{<:WrappedArray{T,N,Src,Dst}}) where {T,N,Src,Dst} = @isdefined(N) ? N : ndims(Dst) |
There was a problem hiding this comment.
This type-piracy is unfortunate. @jakebolewski and I just hunted this down as the source of breaking GPU inference, because Julia doesn't inline this function (might be the unused Src type parameter, e.g. dangling type parameter).
why is the @defined needed here?
There was a problem hiding this comment.
julia> f(a) = eltype(a)
f (generic function with 1 method)
julia> @code_typed f(B)
CodeInfo(
1 ─ return Float64
) => Type{Float64}
julia> using Adapt
[ Info: Precompiling Adapt [79e6a3ab-5dfb-504d-930d-738a2a938a0e]
julia> @code_typed f(B)
CodeInfo(
1 ─ %1 = invoke Main.eltype(_2::SubArray{Float64,1,Array{Float64,2},Tuple{Base.Slice{Base.OneTo{Int64}},Int64},true})::Core.Compiler.Const(Float64, false)
└── return %1
) => Type{Float64}
There was a problem hiding this comment.
why is the
@definedneeded here?
julia> x(::Base.ReshapedArray{Float32,2,Array{Float32,2}})
ERROR: syntax: invalid "::" syntax around REPL[3]:1
Stacktrace:
[1] top-level scope at REPL[3]:1
julia> x(Base.ReshapedArray{Float32,2,Array{Float32,2}})
(Float32, 2)
julia> x(LinearAlgebra.Adjoint{Float32,Array{Float32,2}})
ERROR: UndefVarError: N not defined
Stacktrace:
[1] x(::Type{Adjoint{Float32,Array{Float32,2}}}) at ./REPL[2]:1
[2] top-level scope at REPL[8]:1
For types that 'fix' the N typevar I can't get a hold of it from the WrappedArray union...
It's all a bit of a kludge, admittedly, but it brings us closer to trying out something that might end up in Base some day.
Suggested fix? Adapt.eltype and Adapt.ndims?
There was a problem hiding this comment.
I think making these Adapt.eltype would make sense
No description provided.