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

Good point @jimmyfrasche - will label the issue appropriately.

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.

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.

@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

@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.

@mdempsky totally agree 👍

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?).

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.

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.

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.

For the record: Lua has a # operator instead of a len function (so one can write s[#s-1], or actually s[#s] given Lua's 1-based indexing). That said, it doesn't have s[#] either. On the other hand, it doesn't have table slicing expressions, nor does it support string indexing using an operator.

The refinement of allowing negative constants only is interesting and perhaps worth considering. It does add a particularly special and detailed wrinkle, though. There's nothing similar that I can think of that exists already in the language. And because of that, the exact definition will take lots of discussion and bikeshedding. Literal? Constant? Constant expression? What about cap? etc. etc.

I'm not sure it's a good fit, but it is a clever suggestion.

I think a better proposal would be to accept x[-1] as x[len(x)-1] as in Python.

As explained above by @bradfitz, that's not a good suggestion.

Sorry, missed that.

There is no strong support for this specific proposal, and it requires either adding a new keyword or making some very special treatment of the predeclared identifier len. Closing.