proposal: spec: accept x[len-1] as x[len(x)-1]

[posener]

When applying the index or slice operations on a string/array/slice allow the keyword len inside the brackets. In that case len will mean len(a) where a is the referred string/array/slice variable before the brackets.

For example, if s is of string/array/slice type:

• s[len-1] will be exactly the same as s[len(s)-1]
• s[len-5:len-2] will be exactly the same as s[len(s)-5:len(s)-2]

Pros:

• Readability, specially when the variable name is long.
• Does not add any new keyword to the language.

Cons:

• Will break programs that use len as variable name.

Related issues:

• spec: negative value for slice index #11245

[jimmyfrasche]

len is a predeclared identifier not a keyword so this would add a keyword to the language.

This is a currently valid, albeit silly, program that would be made invalid by this proposal: https://play.golang.org/p/jtQ0U9pQ1H

[mvdan]

Good point @jimmyfrasche - will label the issue appropriately.

[mvdan]

As for the proposed change itself, I think it trades less verbosity for language complexity. Like Jimmy pointed out, you're adding a new keyword. And unlike the old len, this new one can act as both a function and an integer value on its own. I'm not sure s[len-1] would read as easily to newcomers as s[len(s)-1], especially when most code uses len as a function.

In the scope of Go2, I feel that verbosity like s[len(s)-1] and s = append(s, ...) could be improved in many ways. I'm not convinced this change would be a net win.

[mdempsky]

len isn't a keyword, but I don't think we need to make it into one for this proposal to work.

It's currently not valid to use builtin functions outside of a call expression. This would simply be a matter of changing it so len is valid by itself in index and slice expression contexts.

[posener]

@jimmyfrasche It wouldn't change the behavior of the program you wrote, because as @mdempsky pointed out, len outside the brackets is still valid, but it would change the following one:

package main

import "fmt"

func main() {
	len := 1
	a := []int{1,2,3}
	fmt.Println(a[len])
}

I'll update the proposal

[mdempsky]

@posener I disagree with changing the meaning of any existing programs. If len is shadowed by a local variable, then a[len] should use that local variable. It should not mean a[len(a)] in that case.

[posener]

@mdempsky totally agree 👍

[josharian]

I don't think this is going to happen. But if it were, a few other things to consider:

• Side-effects and evaluation order. In f()[len-1], how many times does f get called? Note that this affects whether translating x[len-1] into x[len(x)-1] and back again is a safe transformation.
• Scoping. This appears to introduce a kind of scope. In a[b[len-1]], I presume len refers to b's len, not a. This is a significant additional burden on tools.
• cap as well?
• It's easier to evaluate this kind of suggestion with data. See e.g. the quick-and-dirty exploration of the kinds of for loops people use at https://github.com/josharian/gofor, or the number of select cases people use at https://github.com/josharian/countselectcases.
• I suspect the most common usage by far of this would be for len(x)-1. In that case, a smaller change would be to use constant negative indices, similar to python: x[-1]. Non-constant negative indices would continue to panic, for bug-catching properties (or not?).

[urandom]

Allowing negative indices would cover most of the usages of [len(s)-N]. And since negative indices are pretty common, users wouldn't really be confused by them.

@josharian
Not sure why non-constants should be disallowed. Having [-N] as an index is pretty useful.

[bradfitz]

Making negative indices have special meaning is not going to happen. It's been proposed and rejected a number of times in the past. The rejection reason is that it's too easy to screw up your math and underflow 0 and suddenly get crazy opposite behavior instead of bounds checks runtime errors.

[josharian]

Not that I'm pushing for it, but to be clear, the proposal above was negative constant (or even literal) indices, which I believe mitigates that concern.