Add an `is_resizable` trait?

[rofinn]

It'd be nice if there was an abstract array interface specifying whether an array is resizable in-place.

[ChrisRackauckas]

Agreed.

[oxinabox]

Is it worth distighishing this into: isgrowable for things that can increase size (like Vector) and isresizable that can just shuffle the size around into different dimensions?

Or maybe it is a trait with multiple values:

• Growable() > Resizable > FixedSize ?

[oxinabox]

Really i feel like we want to answer questions about:

• hasmethod(resize!, ...)
• hasmethod(push!, ...) (and maybe its flavours pushfirst!)
• hasmethod(deleteat, ...) (and maybe its flavors pop!, popfirst, filter!)
• maybe hasmethod(reshape,...) ?

[ChrisRackauckas]

If hasmethod is a compile-time "trait", then do we still need a trait for this?

[oxinabox]

Yes, to group them. And to name them. But anyway Jameson says my plan is impossible.

[Tokazama]

I created something similar for this here https://github.com/Tokazama/StaticRanges.jl/blob/f8dac65496c10ea0ec0fbf748006af105f77f62e/src/staticness.jl#L1. It separates things into dynamic, static, fixed. Where a Vector is dynamic, a typical range is fixed, and SVector is static. Would this be a good solution to this?

[ChrisRackauckas]

an isresizable trait function is all that's needed.

[tkf]

FYI, BangBang internally now has implements(f!, x) and possible(f!, args...) to query the capability of containers/objects. ATM only implements(setindex!, x), implements(push!, x), and implements(setproperty!, x) are defined. They are like hasmethod but manually implemented (like @oxinabox mentioned https://github.com/JuliaDiffEq/ArrayInterface.jl/issues/22#issuecomment-518005555). I also need to consider "element" types so that's why there is possible function that can do:

julia> possible(push!, Int[], 1)
true

julia> possible(push!, Int[], 0.5)
false

At some point, I'd like to pull this out of BangBang.jl as a separate library but I also need to deal with non-array containers and objects. So, I don't see ArrayInterface.jl as a good target. It would be great if the part of ArrayInterface.jl that is not array-specific can be factored out.

[Tokazama]

Is this compile time thing or is it all checked at run time?

Sorry if you document it elsewhere but I only read what you linked.

[tkf]

It's all type-level so everything should be done at compile time.

[Tokazama]

If I understand your code correctly you're using a union internally to group mutable and immutable containers. Wouldn't we want to use traits to avoid having to redefine the union type for every new type that needs this behavior?

[tkf]

The Union is just an implementation detail to minimize code duplication. implements is just yet another trait system. You can add anything afterwards. That's how static arrays are treated.

[Tokazama]

Okay, maybe I misunderstood the suggestion. Is your suggestion that instead of defining is_resizeable to have define something like:

implements(::typeof(resize!), ::Type{<:Array}) = true

[tkf]

I'm just mentioning that I explored the API @oxinabox mentioned above https://github.com/JuliaDiffEq/ArrayInterface.jl/issues/22#issuecomment-518005555. (I'm also suggesting to create a new package (upstream to ArrayInterface.jl) that can handle arbitrary containers and objects, not just arrays. But that's not the main topic here.)

[Tokazama]

Perhaps I should open a separate issue for this, but it would also be useful to have grow_first, grow_last, shrink_first, shrink_last. However, I don't know any of the magic behind reserving chunks of memory that this would require for arrays.