Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

language: Expanding the abilities of reslicing slices #4371

Closed
btracey opened this issue Nov 8, 2012 · 6 comments
Closed

language: Expanding the abilities of reslicing slices #4371

btracey opened this issue Nov 8, 2012 · 6 comments

Comments

@btracey
Copy link
Contributor

btracey commented Nov 8, 2012

It would be really nice to expand the reslicing capabilities.

Right now, one can do s[lo:hi] to get the subslice between lo and hi. It would be useful
if one could also do

p := []int{2, 3, 5, 7, 11, 13}
s2 := s[p]

It would also be really nice if one could do
s[lo:2:hi], to take every other element

s[hi:-2:lo], takes every other element in reverse order, etc.

Thank you
@ianlancetaylor
Copy link
Contributor

Comment 1:

You can, of course, write functions to do these operations, although they admittedly
have to be written in terms of a slice of a particular type.  It's not clear why these
operations are the ones to add.  We don't want to add them just because they would be
neat, or because one program would fine them convenient.  We want to add them only if
the benefit they bring to users outweighs the additional complexity in the language and
in the implementation.

Labels changed: added priority-someday, languagechange, removed priority-triage.

Status changed to Thinking.

@minux
Copy link
Member

minux commented Nov 9, 2012

Comment 2:

Labels changed: removed go1.1.

@btracey
Copy link
Contributor Author

btracey commented Nov 10, 2012

Comment 3:

I understand the desire for reducing complexity. I don't think this would be any more
complicated on the programmers side than the re-slicing that already exists, though I
appreciate it does complicate compiling. To clarify, when you say "why these operations
are the ones to add", do you mean in the context of different ways to slice strings, or
in the context of all the operations one could add?

@bradfitz
Copy link
Contributor

Comment 4:

Slicing is supposed to be a super cheap, constant-time operation.
Every other element? Reverse order? Neither of those is cheap or constant time. Go tries
to be readable and be very clear what is potentially expensive and what is cheap.
If the syntax were to change at all, the only desirable thing I've seen is issue #1642
(which is what I thought this bug was at first, hence my commenting here).

@ianlancetaylor
Copy link
Contributor

Comment 5:

When I asked why these are the operations to add, I meant why, of all the possible
meanings we could assign to something like s[a:b:c], should we use the one you suggest? 
And why, out of all the possible complex slicing operations, should we implement these
particular ones and not others?

@rsc
Copy link
Contributor

rsc commented Nov 12, 2012

Comment 6:

The fundamental property of a slice is that it points into the same array as the
original. Slicing with a stride either makes index lookup much more complicated (by
adding the stride calculation into every x[i]) or requires allocating a new slice
(breaking the fundamental property).
I think it's safe to say that strides are not a common enough use case to pay for either
of these costs.

Status changed to WorkingAsIntended.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants