Proposal: Accessing Vector{SVector} with [:, n]

[Datseris]

Would you accept accessing Vector{SVector} with [:, n] , as in

data[:, n] === [d[n] for d in data]

with data <: Vector{SVector} ? I am sure many people use this all the time, would be nice to have the shortcut.

[andyferris]

In theory, it would be nice to use broadcasting. getindex.(array, integer) works. But not so much for non-scalar indexing.

There are competing (and compelling) proposals for the a.[i] syntax, but it might be suitable for this too.

But I’d rather follow the AbstractArray interface to the letter, and open issues/PRs in base Julia when necessary. People need to access nested structures even without StaticArrays - even something seemingly unrelated like (broadcasted) JSON field getting might benefit.

[KristofferC]

That would be type-piracy (it probably wouldn't be very breaking here since it only makes code that used to error, not error) but still.

[Datseris]

Why? SVector comes exclusively from the module StaticArrays. Type piracy is when both the function name and structures used in dispatch are from a foreign module.

Edit: if what you said was the case, then noone would be able to extend getindex, correct?

[KristofferC]

SVector comes from StaticArrays but you talked about extending a base function onto Vector{SVector}.

[andyferris]

@Datseris "Type piracy" is a phrase we use to imply something more specific (and potentially dangerous).

The problem with this kind of change is that much generic code is written to rely on particular interfaces guaranteed by AbstractArray. A user may combine code from Base, library A and library B. The authors of library A only know about the interface and guarantees provided by Base (note that we already allow indexing beyond ndims and it already has a specific meaning) and the author of library B also only knows about Base. When the end user tries to combine routines from library A using concrete types defined in B, those generic routines in A rely on the generic behavior of Base being followed by B, or they will contain logical errors.

A change like this one is not friendly to "blind composition" of generic code. We've discovered over time that one of Julia's main strengths is the ability to perform blind composition, so the community is rather protective against anything that threatens this.

I do agree that concise syntax for this would be useful, which is why I mentioned bringing it up on the Julia repo instead (which obviously can't endanger blind composition since we all rely on Base).

[KristofferC]

The problem with this kind of change is that much generic code is written to rely on particular interfaces guaranteed by AbstractArray

Not only is it breaking the AbstractArray interface but it also changes behavior for a concrete type, which is bad regardless of any interface.

[andyferris]

Well, sure, yes, that makes it slightly worse. It comes in degrees, though; Vector{<:SVector} is an abstract type. The layout of a concrete type depends on the system. And so-on.

[timholy]

@Datseris, you can create a package that supports custom index types, e.g., data[nthitem(n)], and define the corresponding getindex implementation for any AbstractArray type. I did this recently for Interpolations (see implementation, which is much more complicated than this would be).