Indexing with an empty vector "regression"

[jiahao]

julia> [1,2][[]] #v0.4
ERROR: MethodError: `_checkbounds` has no method matching _checkbounds(::Int64, ::Array{Any,1})
Closest candidates are:
  _checkbounds(::Any, ::Integer)
  _checkbounds(::Any, ::Real)
  _checkbounds(::Any, ::Range{Int64})
  ...
 in getindex at abstractarray.jl:464

julia> [1,2][[]] #v0.3
0-element Array{None,1}

Prodding a bit more shows that this issue is due to [] now being a synonym for Any[] rather than None[]:

julia> [1,2][Int[]] #both 0.3 and 0.4 ok
0-element Array{Int64,1}:

julia> [1,2][Any[]] #both 0.3 and 0.4 error
ERROR: `checkbounds` has no method matching checkbounds(::Int64, ::Array{Any,1})
 in checkbounds at abstractarray.jl:94
 in getindex at multidimensional.jl:49

@andreasnoack suggests one fix is to relax the typevar restriction in the definition of Base._checkbounds. Doing so leads to

julia> [1,2,3][Any[1]]
ERROR: invalid index: Any[1]
 in error at ./error.jl:21
 in getindex at abstractarray.jl:464

I'm not sure if this is fixable, or worth fixing even. Thoughts?

[yuyichao]

No strong preference.

Ref https://groups.google.com/forum/?fromgroups=#!topic/julia-users/Z59s12-HEyk

[hayd]

Similar weird (?) behaviour:

julia> [1, 2][]
1

julia> [1 2; 3 4][]
1

[hayd]

@malmaud Should the behaviour I mention above be a separate issue or is it expected?

[mbauman]

@hayd, that behavior is intentional. [] is synonymous with [1]. Its intended use-case is for zero-dimensional arrays and Ref de-referencing, but it works with all arrays (similar to how linear indexing works with multidimensional arrays).

[hayd]

Thanks!

[StefanKarpinski]

I'm generally not super jazzed about how many different kinds of indexing we allow into multidimensional arrays. I would prefer it only linear and N-dimensional indexing were allowed. In fact, now that we have generated functions and eachindex, which allow doing N-dimensional indexing in a fast generic way, there's a pretty strong case to be made for dropping linear indexing entirely. But that is a matter to be settled in the Arraymaggeddon.

[mbauman]

It can be really powerful, but it's also an easy source of mistakes. I'd definitely be interested in trying it out. I think it could even be deprecated nicely, which makes experimenting with it much easier.

[StefanKarpinski]

Note that you could still express linear indexing using reshape if you really need it, but not allowing it by default would prevent mistaken usage as well as encourage writing code in a more generic style that will work for non-contiguous arrays. In fact, one could then imagine eliminating the contiguous vs non-contiguous distinction, which would make the array view business much simpler. Are non-contiguous strided arrays closed under slicing with scalars and ranges?

[timholy]

Now that we have nice iterators I generally dislike linear indexing, but I have the impression that there are still cases where it may be more performant. We still have #9080 to deal with, for example.

[timholy]

Are non-contiguous strided arrays closed under slicing with scalars and ranges?

If you don't change dimensionality (i.e., use N-dimensional indexing for an N-dimensional array), everything is closed. Once you change dimensionality, all bets are off.

[StefanKarpinski]

I think there's a lot to be said for only having one strided array type and having that be what is returned by all scalar/range slices, with no copying. We would probably need GC support for interior pointers, but I think we'll need that for strings too, so we may as well do it. For performance, we can always dynamically check whether linear indexing is applicable and do linear indexing if it is. I think the occasional complexity that would add to a few functions would be well worth it for the massive simplification we would get from collapsing arrays, strided arrays and array views into a single type.

[timholy]

SubArrays pretty much do all that already, except the linear indexing check is done at construction time.

[ScottPJones]

What were you thinking of, for GC support for interior pointers?
Could it simply be only keep pointers to the base of GCed memory, paired with an offset to the actual position?
That's how we had to handle references to shared memory (base pointer + offset), where each process might have the shared memory mapped at a different address.