TileArray and the AbstractArray interface

[AntonOresten]

TileArray is currently not an AbstractArray, meaning many methods need to be explicitly defined (Base.eltype, Base.ndims), and in kernels the only way to access the global size is through the sizes field, which would be nicer to access through Base.size and Base.size(_, i).

TileArray isn't used like a normal array, but is there anything preventing us from subtyping AbstractArray and only defining Base.size? It doesn't fit neatly into the interface since I suppose we don't care about Julia-side element access, so a custom Base.show method might also be needed for displaying it to not error.

[maleadt]

Same applies for Tile, I guess, which also has many of these properties.

That said, I'm not sure it buys us much except for some trivial definitions. Most of the functionality would actually require scalar getindex/setindex, so wouldn't work.

[AntonOresten]

Right, this is why I was a little hesitant. But you agree we could use some more QoL methods?

I see #67 added many useful methods for Tile:

Base.size(::Tile{T, Shape}) where {T, Shape} = size(Tile{T, Shape})
Base.size(t::Tile, d::Integer) = size(typeof(t), d)
Base.ndims(::Tile{T, Shape}) where {T, Shape} = ndims(Tile{T, Shape})
Base.length(t::Tile) = length(typeof(t))

I can make a PR for TileArray.

[maleadt]

But you agree we could use some more QoL methods?

Yes, definitely. I'm just not convinced <:AbstractArray buys us much. I had considered it in order to get some of the sum -> reduce -> mapreduce -> mapreducedim! stack, but even there it wouldn't result in that much savings.