Method inheritance

[bramtayl]

If these were inferable, defining interfaces could be quite a bit robust. For example, you could define is_abstract_array(x) = hasmethod(eltype, Tuple{typeof(x)}) && hasmethod(getindex, Tuple{typeof(x), Int}).

Edit: constant propagatable hasproperty would also be cool

[bramtayl]

And in fact, a lot of previously defined traits could disappear. HasLength, HasSize, HasEltype, etc.

[bramtayl]

After thinking about this for an hour I don't think this would be useful. For example, if you defined:

length(x::MyType) = rand(Bool) ? 1 : error() then even though a method for length is defined, length isn't really defined... I'm sure there are complicated trait-based systems that can handle this better.

[bramtayl]

Ok, here's a better system that I think is actually workable. Instead of relying on traits like HasEltype, instead use:

@inline required_method(::typeof(eltype), a::AbstractArray) = true
@inline required_method(::typeof(eltype), anything) = false

and then instead of dispatching based on AbstractArray, do

function collect(x)
    if required_method(eltype, x) && required_method(axes, x) && required_method(getindex, x, 1)
        # abstract array assumptions
    else
        # general iterator assumptions
    end
end

[bramtayl]

Ok so this is actually kinda a cool idea right?

[StefanKarpinski]

Perhaps? I'm a little unclear on what you're proposing / requesting here.

[bramtayl]

Instead of relying on duck-typing, we could do compile-tile math to check for the existence of required methods.

[bramtayl]

Does that makes sense? Or am I crazy

[favba]

I felt the need for a similar feature when I was writing my own ReinterpretArray.
I was trying to define a struct that is a wrapper around an AbstractArray.
If the array is a DenseArray so my array wrapper should be and all defined methods for DenseArray should just work (BLAS routines calls, FFTW).
But currently, with type dispatch system instead of trait dispatch, I wasn't able to do that.
So I had to define two struct that behaves exactly the same in order for that to work.

[bramtayl]

So here's a more detailed example:

to_type(x) = typeof(x)
to_type(x::Type) = x

"""
    works(f_type::Type, in_types::Type...)

Check whether a function of type `f_type` is expected to work on arguments of types `in_types`.

    works(f, ins...) = works(typeof(f), typeof.(ins)...)

Provided for convenience; define new `works` methods `Type` arguments.
"""
works(ins...) = works(to_type.(ins)...)
works(::Vararg{Type}) = false
works(::Type{F}, ::Type{A}) where {F <: typeof(size), A <: AbstractArray} = true
works(::Type{F}, ::Type{A}, ::Vararg{Type{Int}, N}) where {N, F <: typeof(getindex), A <: AbstractArray{T, N} where {T}} = true
works(::Type{F}, ::Type{A}, ::Vararg{Type{Int}, N}) where {N, F <: typeof(setindex!), A <: AbstractArray{T, N} where {T}} = true

using Test: @test
@test works(size, [1])
@test works(getindex, [1], 1)
@test works(setindex!, [1], 1)

has_linear_indices(x) = works(size, x) & works(getindex, x, 1) & works(setindex!, x, 1)
@test has_linear_indices([1])
@code_warntype has_linear_indices([1])
# return true

What do people think?

[bramtayl]

@StefanKarpinski does that clear things up?

[StefanKarpinski]

Doesn't applicable do this already?

[bramtayl]

Sort of, but applicable doesn't constant infer (so you can't use it for dispatch), and the semantics are slightly difference. applicable checks whether a method is defined, whereas works would check whether a method is expected as part of an interface.