Go Programming Experience
Experienced
Other Languages Experience
Go, Perl, Java, C, JavaScript, bash, REBOL, Pascal
Related Idea
- [ ] Has this idea, or one like it, been proposed before?
- [ ] Does this affect error handling?
- [ ] Is this about generics?
- [x] Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit
Has this idea, or one like it, been proposed before?
No.
Does this affect error handling?
No.
Is this about generics?
No.
Proposal
Add a slice-- statement as syntactic sugar for slice = slice[:len(slice)-1]: remove the last element of the slice.
Add a slice++ statement as syntactic sugar for slice = slice[1:]: remove the first element of the slice.
This extend the decrement/increment statements to addressable slice expressions.
The slice = slice[:len(slice)-1] idiom is a complex expression. Count in the standard library:
$ grep -Er '(\w+) = \1\[:len\(\1\)-1\]($|\s+//)' $(go env GOROOT)/src | wc -l
192
$ grep -Er '(\w+) = \1\[1:\]($|\s+//)' $(go env GOROOT)/src | wc -l
363
While string are in many case manipulated like slices, this proposal does NOT extend to string types (but the count above unfortunately doesn't distinguish string cases) because I think that the semantic of -- applied to a string is not as obvious as for slices. We might however consider that case later depending on feedback.
Language Spec Changes
No change in lexer.
In IncDec statements add increment/decrement on adressable (or map index) expressions of type slice.
Informal Change
The slice-- statement removes the last element from the slice. That statement is a shortcut for slice = slice[:len(slice)-1].
The slice++ statement removes the first element from the slice. That statement is a shortcut for slice = slice[1:].
Is this change backward compatible?
Yes.
This is just an extension of Inc/Dec statements to values of type slice.
Orthogonality: How does this change interact or overlap with existing features?
This extends the use of an existing syntax to more types.
Would this change make Go easier or harder to learn, and why?
Maybe slightly harder to learn because slices are specific to Go and this new syntax is related to slices. This additional syntax doesn't have parallel in other languages I know.
However this improves readability of two common slices idioms, in particular the decrement one.
Cost Description
A new (alternative) syntax for niche cases?
That new syntax doesn't have [ and ] that makes a slice expression immediately visually recognizable.
Changes to Go ToolChain
All tools that do type checking ; compiler
Performance Costs
No runtime cost. Minor compile time cost.
Prototype
I don't know the internals of the toolchain, so here are some very rough ideas.
No lexer change. No go/ast change.
Probably changes in package go/types where *ast.IncDecStmt is handled (stmt.go).
On the compiler side, a naive implementation would patch the AST in the frontend to expand the expression as slice = slice[:len(slice)-1] or slice = slice[:1]. However a better implementation would be at IR level: just check if the operation is allowed (checking for a valid slice with length >= 1) and then decrement the length in the slice header.
Comment From: gabyhelp
Related Issues
- proposal: spec: treat s[-1] as equivalent to s[len(s)-1] #25594
- proposal: Go 2: allow 3-index slices to elide the second (length) term #38081 (closed)
- proposal: x/exp/slices: add First and Last #53510 (closed)
- proposal: slices: new First and Last functions #69909 (closed)
- proposal: Go 2: '..' as alternative syntax for slicing #64118 (closed)
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)