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
Labels
Comments
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. |
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? |
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). |
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? |
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. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: