Rename `getindex` and `setindex!` to operator form

[timholy]

A discussion on slack suggested that getindex is confusing and should perhaps be called getatindex (which is not quite as readable). But if we could write this in operator form

julia> Base.:(==)
== (generic function with 165 methods)

julia> Base.:([])
ERROR: syntax: invalid syntax "Base.[]" around REPL[2]:1
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

(it's good that it throws an error now, that means it's available) then we could add a custom array type and define

Base.:([])(A::MySpecialArray, i::Int) = ...

It would seem this doesn't even have to wait for Julia 2.0; that could be when we delete the older names.

[MasonProtter]

But like... Why?

[mkitti]

But like... Why?

The name getindex is counterintuitive. Coming from other language conventions, one might expect this to return an index rather than the value at the index given as an argument. In other circumstances, such as getindex(::RefValue), there is no index argument at all.

In the near term, it may improve the legibility of code if this was more clearly connected with the square bracket syntax using an alias.

Could we turn [] into an operator as in C++ without being enormously disruptive?

[MasonProtter]

I think getindex(v, i) is maybe counterintuitive if you think too hard about it for like one or two encounters and then would be fine. On the other hand, code like

Base.:([])(v::MyType, i...) = #...

is at risk of being confusing and opaque every time you look at it. This idea is cute, but imo deprecating getindex in favour of it is a cure far worse than the disease.

[mkitti]

In thinking about the potential implications, one that arises is that [] alone is currently interpreted as Base.vect() which results in Any[]. It may be best to contain this within abaremodule.

[mbauman]

Yes, I fear [] is too overloaded for this to be sensible. One advantage to the "operator" name, though, is that it can be lexically overridden. For example, A' lowers to var"'"(A), and var"'" is simply bound to Base.adjoint. This allows you to lexically shadow the behavior of ' within a given scope without messing up Base.adjoint.

In contrast, A[] lowers directly to Base.getindex. This is what broke 2-based indexing.

[mkitti]

The var approach is interesting. Essentially, we can create an alias Base.var"[]" for Base.getindex in the following way.

julia> @eval Base var"[]" = getindex
getindex (generic function with 207 methods)

julia> struct MyConstantArray{C} end

julia> Base.var"[]"(::MyConstantArray{C}, i::Int) where C = C

julia> c = MyConstantArray{5}()
MyConstantArray{5}()

julia> c[3]
5

julia> c[10]
5

[haampie]

.:([]) looks more like ascii art than a reference to a function to me 😬. even C++'s weird operator[] is more humanly decodable than this.

julia> macro operator_str(str)
         esc(Symbol(:operator, str))
       end
@operator_str (macro with 1 method)

julia> operator"[]"
ERROR: UndefVarError: operator[] not defined
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

julia> operator"[]" = getindex
getindex (generic function with 208 methods)

julia> operator"[]"(rand(3), 1)
0.10244386495710267

How do you distinguish between setindex! and getindex here though? In C++ that's through operator[](...) const, so I suppose operator"[] const" = getindex

[JeffBezanson]

In thinking about the potential implications, one that arises is that [] alone is currently interpreted as Base.vect()

This is a key point to me. The syntax [] already means something else, so reusing it for something slightly different is hardly a model of clarity. The syntax a[b] is also not really "operator syntax", so calling it [] to me has the dual problems that (1) it's already a strange non-standard way to name something, and (2) it doesn't correspond directly to how it's used. If the indexing syntax were a [] b it would be ok I guess.

getatindex vs. getindex seems a bit pedantic to me. Sure, you can argue that it's more accurate, but I bet nobody would guess it either. But, there are some precedents for getindex getting an index instead of an element, e.g. in java. Python uses __getitem__. We have getkey, so maybe getvalue, to pair with that? I'm willing to consider a renaming like that for 2.0.

[MasonProtter]

In contrast, A[] lowers directly to Base.getindex. This is what broke 2-based indexing.

Couldn’t we just do this lexically as well? Lower it to getindex instead of Base.getindex. I don’t see why the operator form would change that.

[mbauman]

We used to do exactly that, but it changed in a grand reckoning on lowering pre-1.0 (breaking TwoBasedIndexing.jl). The informal rule is that we shouldn't lower to something you didn't write. The rationale here is well-motivated, IMO. You wrote A[]. There's no reason to think that writing getindex = 2 in the same scope would break that.

So using a name that resembled var"[]" or something like it could possibly allow following that rule — because it looks like it could actually have an effect.

[JeffBezanson]

The not-yet-implemented plan there was to lower to __getindex__, so you can still override it lexically but user variables won't be captured.

[mkitti]

I dug and found the inception of the name getindex. It came as the counterpart to setindex!.
#907 (comment)

Consider that we also have getproperty, and getfield, which take the property name and field name as the second argument. Being more verbose, these could be getbypropertyname or getbyfieldname just as getindex could be getbyindex. A method named getvalue could apply to an element that is a member of an indexed array, a property, or a field, thus getvalue seems ambiguous. In this sense, there seems to be a consistent habit of dropping prepositions and being brief for the method names getindex, getproperty, and getfield.

getkey seems out of place out of the getX names because its meaning is actually read literally. It's not getbykey, which is just get.

[mkitti]

TL;DR An alias for getindex that uses square brackets increases the comprehension of code. Renaming is for another time.

While the title of this issue suggests renaming, the present question is really if there should be an alias. We are all agreed that this is not the time for a renaming and deprecation to occur. It either should have been done very early on (0.2) or later in a 2.0.

An alias that uses the characters [ and ] would help make the connection between the squares brackets and getindex discoverable and concrete. It would also be helpful in situations where getindex is non-sensical but [] is used.

For example, applied to Ref, getindex seems quite awkward since no index argument is present. Yes, one could argue that these are 0-dimensional arrays, but we actually do have an index for that, an instance of CartesianIndex{0}.

julia/base/refvalue.jl

Lines 56 to 57 in d633726

	getindex(b::RefValue) = b.x
	setindex!(b::RefValue, x) = (b.x = x; b)

Another example brought up in Slack, is its use in getindex(::Type{T}, vals...) where T for syntax such as Int8[-1, 3, -5]. Here we are exploiting the syntax and are not using an index at all.

julia/base/array.jl

Line 403 in d633726

function getindex(::Type{T}, vals...) where T

In each of the above examples, perhaps it would have been intuitive to use a method name that refers to square brackets rather than indices. If examples such as this already occur in Base, surely they will also be common place in user packages.

By adding an alias that has square brackets in the name, we could increase the human comprehension of code, especially when the method is being used in a manner that focuses on the syntax rather than the indexing operation.

[haampie]

What alias would you propose for setindex! then for symmetry?

[mkitti]

What alias would you propose for setindex! then for symmetry?

Since we don't like calling this an operator, how about var"get[]" and var"set[]!" as aliases for getindex and setindex!. It also differentiates the method from cat, vcat, hcat, hvcat, etc.