b := s[1:4]	// len == 3, contains {3, 4, 5}

No. b is the same as a here. It contains {2, 3, 4}.

Not sure what you are intending. But if something is unclear in the spec, please be clearer about what it is that is confusing. You're proposing a fix and I don't understand what the problem is.

yes, here b is same as a. i wrote them as example.

i am asking for a sentence in the spec that specify the elements using a interval notation.

@Cubte would you please review https://golang.org/ref/spec#Slice_expressions and explain how you would like to see it improved.

The spec does not specify which elements get included in the resulting slice using words. It is demonstrated using example code.

The indices low and high select which elements of operand a appear in the result.

Please remember that a subslice is not a copy of the contents of the source slice, it creates a new slice header value suitably adjusted.

[low, high) and (low, high] have the same length.

True, but the subslice is [low:high) not (low, high]. Are you saying that you would like to see that state explicitly in the spec?

Are you saying that you would like to see that state explicitly in the spec?

Yes.

Thank you for explaining.

/cc @ianlancetaylor

It seems clear to me:

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

the slice s has type []int, length 3, capacity 4, and elements

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

I don't see any possibility for confusion here. It shows exactly the entries in the resulting slice. You can map them back to the input array easily enough.

Note that the prose says explicitly: "The indices low and high select which elements of operand a appear in the result."

The reason for the example's choice of element values 1, 2, 3, 4, 5 is exactly so we don't need to introduce another formalism but can illustrate the behavior with a simple example in case it shouldn't be already clear from the prose.

Happy to revisit if you have a concrete suggestion as to how to make this clearer without making it more complicated. Closing for now. Thanks.

Note that the prose says explicitly: "The indices low and high select which elements of operand a appear in the result."

But it does not say exactly which elements gets selected.

The reason for the example's choice of element values 1, 2, 3, 4, 5 is exactly so we don't need to introduce another formalism but can illustrate the behavior with a simple example in case it shouldn't be already clear from the prose.

I think that sentence doesn't make it fully clear. Instead it requires to explicitly rely on the example.

An interval notation specifying the indices of elements get selected from operand can make it much better to understand. Then the example will be an example.

It may not be "fully clear" in a mathematical sense, but it is sufficiently obvious what is meant that for 12+ years nobody objected.

As I said, I am not against improving this if you send us a concrete suggestion that is clearly better and just as easy to read. Thanks.

for 12+ years nobody objected.

Maybe everyone here is old and took it for granted. But i am 19 years old and i can't.

I am not a native English speaker. Constructing such sentence is relatively hard for me. I wish you will understand me and improve this.

The best i have tried is,

Elements from index low to high - 1 of operand a appear in result.

@griesemer will this change?

I looked at this again. The suggestion "Elements from index low to high - 1 of operand a appear in result." looks promising at first but doesn't hold up: a[0:0] is valid and leads to an empty result, but speaking of element high - 1 which would be element at index -1 is rather confusing.

The current prose says: "The indices low and high select which elements of operand a appear in the result." Together with the next sentence "The result has indices starting at 0 and length equal to high-low." it's pretty clear what is meant. To make it extra clear, we have an example.

One could talk about the non-inclusive (for the upper end) interval [low, high) of elements etc. but it gets quickly and needlessly complicated for little reason. At least I haven't seen a much better suggestion and this is not important enough for the Go team to spend time on.

More generally speaking, we have tried to strike a balance between precision and readability in the spec. Sometimes we have sacrificed a bit of precision if favor of a simpler and more compact prose if the meaning of the prose seemed obvious enough. This may be one of those cases. Please also note that while we intend the spec to be fairly easy to read and understand, it is not a tutorial into programming or into Go. There's plenty of other literature.

In summary, this is not going to change at this point. Thanks.

Related: #43545.