scope of getindex and setindex

[JeffBezanson]

Currently most syntax that looks different from the underlying function name calls Base. For example [a,b] calls Base.vcat. For whatever reason a[i] calls getindex in the current scope, instead. This should probably change but I want to call people's attention to it.

[toivoh]

I thought that it was meant to go in the other direction. Weren't you
supposed to be able to customize these things in your own module if you
really wanted too? At least, + still doesn't call into Base, right?

[StefanKarpinski]

I also thought that the whole point of the rename to setindex! and getindex was that these names were less likely to accidentally be overridden in modules and that we were planning on calling the local version.

[JeffBezanson]

I don't think + ever called Base (though Base.Operators is imported by default). This is only an issue for things that don't look like what they are really called. For example a possible bug used to be

    ref = 0
    a[i]   # error

I would be fine with going the other way and calling the local versions; the real problem is the inconsistency. The full list of affected identifiers is: colon, hcat, vcat, hvcat, getindex, setindex!, transpose, ctranspose.

[mlubin]

I'd vote in favor of calling Base. I think calling the local versions introduces a serious code readability issue.

[StefanKarpinski]

I lean pretty strongly in the other direction since otherwise you can't use normal syntax in a module while defining entirely new generic functions for these operations. There's no real readability issue because normal modules import the Base versions of these by default, so the two behaviors are indistinguishable. To that end, I do think that all of these identifiers should be imported by default. Some of their names are problematic in that they might rather easily be accidentally overwritten (e.g. transpose). Perhaps this is a good place for the __foo__ naming style.

[johnmyleswhite]

I also lean towards always calling the local bindings for these names. I don't see why we need to use __foo__ names when we can't have variables called type, which seems much more useful than having variables called transpose or setindex!. My personal preference is that we issue much more intense warnings when clobbering names in Base (e.g. something like Array = 10 should elicit a chastising warning, not succeed).

[StefanKarpinski]

It would be great to allow variables named type, but it's not possible to have global variables by that name without making parsing insane. Would the word type in a module begin a type declaration or is it a reference to a variable? If you assigned to a variable named type then how would you declare a new type? Since we don't allow type declarations inside functions, we could allow it as a local variable name, but then there are names that are allowed as local variables but not as global variables, which is rather awful.

We already allow variables called transpose and setindex! – it's just that they have a special meaning. The issues is that it's fairly easy for someone to come along, say in the repl, and do transpose = X.' and suddenly have transposition not work – so, in particular, you can't even execute that expression again, since it's equivalent to transpose = transpose(X), which obviously won't work when transpose is a matrix.

The reason we allow overwriting constants with only a warning is that otherwise reloading code would be impossible. As it is, reloading code generally redefines some variables and constants and therefore issues some warnings, but often works. Moreover, Array = 10 still wouldn't be an error since Array is only in the default namespace via using, which means that if you write Array = 10 before using Array anywhere, you're simply indicating that you didn't want that binding from Base.

[JeffBezanson]

OK, I will make them call the local names and add them to Base.Operators. This way they behave exactly like other operators, just with less-obvious names. Can be thought of as a+b => +(a,b), and a:b => colon(a,b).
I will also add more mention of this in the docs. It is discussed a bit in the Arrays chapter, but I think it doesn't hurt to mention it in multiple places.

[JeffBezanson]

From this I just discovered that the FFTW transpose routines are local to the FFTW module, and therefore aren't getting called. They also seem not to work for rectangular matrices:

julia> a=rand(2,3)
2x3 Array{Float64,2}:
 0.546268  0.143648  0.937938
 0.145376  0.682795  0.744402

julia> a'
2x3 Array{Float64,2}:
 0.546268  0.145376  0.143648
 0.682795  0.937938  0.744402

@stevengj

[stevengj]

They used to be called, but were replaced in #3219. In the old code, the FFTW.transpose routines were called for rectangular matrices that had already been reshaped into their transposed shape, in which case they worked, but I agree that this is a bit counter-intuitive. Maybe they should just be deleted?