proposal: spec: treat s[-1] as equivalent to s[len(s)-1]

[josharian]

Overview

This is a backwards-compatible language change proposal. It will not be as thorough as it could be, since I do not think it should be adopted. I am writing it up merely for future reference.

I propose to treat negative constant literals in slicing and indexing expressions as offsets from the end of the slice or array. For example:

• s[-1] is equivalent to s[len(s)-1]
• s[:-1] is equivalent to s[:len(s)-1]
• s[:-2:-1] is equivalent to s[:len(s)-2:len(s)-1]

The motivation is to improve readability. Slice and index expressions like this occur commonly when treating slices as stacks.

Consider this code from the compiler:

func (f *Func) newPoset() *poset {
	if len(f.Cache.scrPoset) > 0 {
		po := f.Cache.scrPoset[len(f.Cache.scrPoset)-1]
		f.Cache.scrPoset = f.Cache.scrPoset[:len(f.Cache.scrPoset)-1]
		return po
	}
	return newPoset()
}

Using the proposed syntactic sugar, it would read:

func (f *Func) newPoset() *poset {
	if len(f.Cache.scrPoset) > 0 {
		po := f.Cache.scrPoset[-1]
		f.Cache.scrPoset = f.Cache.scrPoset[:-1]
		return po
	}
	return newPoset()
}

Scope

The proposed sugar would only apply to negative constant literals.

var b [10]byte
var v int = -1

const c = -1

var (
	_ = b[v]  // unchanged: results in runtime panic
	_ = b[c]  // unchanged: results in compile time error: index bounds out of range
	_ = b[-1] // new: evaluates to b[len(b)-1]
)

The rationale for b[v] to panic at runtime is that negative indices often arise due to overflow and programmer error.

The same rationale discourages allowing constant expressions such as b[c] as syntactic sugar. Constant expressions can be complex, non-local, and build-tag controlled.

However, a constant literal displays clear, obvious, local intent, and overflow-free, and affords little room for programmer error.

Order of evaluation and side-effects

Currently, the slice/array is evaluated before any index or slice indices. See https://play.golang.org/p/kTr9Az5HoDj.

This allows a natural order of evaluation for the proposal. Given expr[-1] or expr[:-1], expr is evaluated exactly once, and its length is used in subsequent len(expr)-c calculations.

Data

A quick-and-dirty AST parsing program examining slice expressions suggests that such expressions occur, but not with particularly high frequency.

Running over GOROOT yields that 2.51% of slice expressions could be rewritten to use this syntactic sugar. Running over my GOPATH yields 3.17%. Searching for candidate index expressions yields 0.35% and 0.91% respectively.

This is an underestimate. In many cases, for clarity, the code will already have been rewritten like:

n := len(s)-1
x = s[n]
s = s[:n]

And all index expressions were considered candidates for this analysis, which includes map accesses and assignments.

Nevertheless, this analysis suggests that this sugar is unlikely to be transformative in how Go code is written, and therefore probably does not pull its weight.

[mvdan]

Similar proposal in the past: #20176

[ianlancetaylor]

Also #11245, but this variant is, on the one hand, better because because it doesn't accept variables, but, on the other hand, worse because why should we only accept constants?

[josharian]

@mvdan yes, this proposal was follow-up to a suggestion mooted during the conversation in #20176. I should have noted that.

@ianlancetaylor indeed. The best argument I see for the discrepancy is one of practicality: variables (and constant expressions) and constant literals should be treated differently because doing so affords increased readability without increasing the probability of silent bugs. But I agree that that isn’t a particularly compelling argument, given the small proportion of code that matches the pattern.

[cznic]

How does adding an exception to an expression (-1 in some cases is to be read as len(foo)-1) improve readability? Please explain, for me it's quite the opposite.

[josharian]

@gopherbot please close this issue in 48 hours.

(That obviously doesn’t work. But I wish it did. I’ll be the bot.)

[josharian]

@cznic the same way all syntactic sugar does: By providing a mental shortcut for common uses. Instead of having to parse out everything and confirm equivalence of the inner/outer expressions, I see [-1] and think “final element”.

[as]

That would be more natural if the indices of the slice s were treated as elements in a ring of order len(s).

[DeedleFake]

I don't think is usually that much of a big deal usually, but I've wanted this feature sometimes for cases where I'm indexing into a slice that isn't bound to a variable. For example, given func Example() []string, I've occasionally wanted to do something like Example()[:-1] for various reasons. Similarly, if the slice has a really long identifier for some reason, it definitely improves readability if using the name twice on the same line would make it annoyingly long. Of course, in either of these cases you could probably just stick it in a variable most of the time, but there are occasionally instances where that's kind of annoying.

Not the best examples, perhaps, but I think that it could be useful in these cases.