proposal: Go 2: '..' as alternative syntax for slicing

[Goclipse27]

Proposal :

Slicing is one of the important operation in Golang while dealing with slices or arrays. Currently colon operator is used :
It looks like this

a := [5]int{1, 2, 3, 4, 5}
s := a[1:4]

if you search across a go file or func most of local variables are driven through short term variable declaration :=, you may be even able to notice that above. However if you see slicing as an operation, it is basically getting a part from the underlying array either getting it with above index or getting then all it is better denoted by range operators like in shell (..) as currently vardiac symbols are used for Passing arguments to ... parameters If f is [variadic](https://go.dev/ref/spec#Function_types) with a final parameter p of type ...T, then within f the type of p is equivalent to type []T

If the final argument is assignable to a slice type []T and is followed by ..., it is passed unchanged as the value for a ...T parameter. In this case no new slice is created.

s := []string{"James", "Jasmine"}
Greeting("goodbye:", s...)

func Greeting(prefix string, who ...string)

or The notation ... specifies an array length equal to the maximum element index plus one.

days := [...]string{"Sat", "Sun"} // len(days) == 2

So i am proposing 2 dots or .. as a notion for slicing operation with or without index and I can show some examples below

How the change looks like

Current

1. Simple slice expressions

The primary expression

a[low : high]

Proposed

a[low .. high]

Example

a := [5]int{1, 2, 3, 4, 5}
s := a[1 .. 4]

the slice s has type []int, length 3, capacity 4, and elements , this doesn't change slicing behavior and same as s[1:4]

s[0] == 2
s[1] == 3
s[2] == 4

For convenience, any of the indices may be omitted. A missing low index defaults to zero; a missing high index defaults to the length of the sliced operand:

a[2..]  // same as a[2 : len(a)]
a[..3]  // same as a[0 : 3]
a[..]   // same as a[0 : len(a)] ; 

2. Full slice expressions

The primary expression

a[low : high : max]

Proposed

a[low .. high ; max]

Example

a := [5]int{1, 2, 3, 4, 5}
t := a[1 .. 3 ; 5]

the slice t has type []int, length 2, capacity 4, and elements

[randall77]

You can already do what you want without a new operator?

a[2..]  // same as a[2 : len(a)]

That's the same as a[2:]

> a[..3]  // same as a[0 : 3]

That's the same as a[:3]

> a[..]   // same as a[0 : len(a)]

That's the same as a[:]

[Goclipse27]

@randall77 - But overwhelming association of short term declaration := in the file while search slicing and short term declaration is pretty rough as already horizontal ellipses ... gives meaning variable params and in array as well where .. is closer to that and feels like in the spectrum of operators.

[randall77]

I don't think we want to change the language, which is a very big deal, just to make text search for slicing easier.

[seankhliao]

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

[Goclipse27]

I will do @seankhliao

[Goclipse27]

@seankhliao The template has questions, how to make answer them and respond. Fork and PR?

[seankhliao]

copy and answer them here

[Goclipse27]

Would you consider yourself a novice, intermediate, or experienced Go programmer?
May be Intermediate - as I have built elf-ebf , which is cgo 😛

What other languages do you have experience with?
Java, bit of Python.

Would this change make Go easier or harder to learn, and why?
The change will make Golang slicing more easier, meaningful and more idiomatic way. Saying I am going to get slice from index 2 to index 5 elements in array like 2..5 -> This clearly says you are moving from 2 to 5 rather than saying [2:5]. And above all already arrays do have [...] and vardiac params has the same notion too and it aligns with them.

Has this idea, or one like it, been proposed before?
I don't think so
If so, how does this proposal differ?
NA
Who does this proposal help, and why?
All the developers community. It is more meaning while we say we iterate over range where we call range with 2.. , 1..5, ..3 This is what range means, I believe. And : is used more on short term declaration and switch: , which is of more of declaration statements.

What is the proposed change?
proposal: Go 2: '..' as alternative syntax for slicing

Please describe as precisely as possible the change to the language.

Adding a .. operator for slicing will improve Golang over all in terms of slice. If you want to search where slice is used in the language it will be easier. As this operator will be dedicated to that operation where as : is used in pretty much other places as mentioned above.

What would change in the language spec?
https://go.dev/ref/spec#Operators_and_punctuation

Please also describe the change informally, as in a class teaching Go.
#64118 (comment)

Is this change backward compatible?
This is not backward compatible. This is going into new list of operators

Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
Show example code before and after the change.
May be we retain slicing operator : while adding .. as both available and let us evaluate the developers usage. Since : is combined with = another operators, I wish slicing had a separate operator and inline with its peers [...]

What is the cost of this proposal? (Every language change has a cost).
More meaningful, more classic and contemporary way of saying it.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
all of them

What is the compile time cost?
No Cost

What is the run time cost?
No Cost

Can you describe a possible implementation?
#64118 (comment)

Do you have a prototype? (This is not required.)
Not Available

How would the language spec change?
Some of which I have covered here - #64118 (comment)

Orthogonality: how does this change interact or overlap with existing features?
This is intended for replacing a syntax. We can make them co-exist as well that depends on the decision.

Is the goal of this change a performance improvement?
No

If so, what quantifiable improvement should we expect?
Not Applicable

How would we measure it?
Not Applicable

Does this affect error handling?
Not Applicable

If so, how does this differ from previous error handling proposals?
Not Applicable
Is this about generics?
Not Applicable
If so, how does this relate to the accepted design and other generics proposals?
Not Applicable

Note : Please let me know If I missing something

[kurahaupo]

This proposal introduces an entirely new token that is functionally indistinguishable from the colon. That alone makes it hard to justify, and I don't support it as it creates duplication (and therefore confusion) for extremely minimal benefit.

It's not like it's hard to search for \[.*:.*\].

But if this proposal were to move forward I'd prefer to use the existing token ... instead of creating .. anew.

[adonovan]

Given that this is just an alternative syntax for an existing feature, this is a likely decline. Leaving open for a further four weeks for final discussion.

[findleyr]

No change in consensus, so declined.
— rfindley for the language proposal review group