-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
slices: new standard library package based on x/exp/slices #57433
Comments
Out of interest: Is there code which would compile with the current version but would stop compiling with my proposal? I can't really think of how that would be the case, because any code using |
Usage statistics per function would be interesting. If there's a function that isn't used at all, that could be a sign that it's not necessary. |
I don't know if it has been brought up, but I also find it a bit of a rough edge that it's sometimes |
I think it was discussed in #53983 |
Fair enough. |
I had to think about it, but I think the answer is yes: f := slices.BinarySearchFunc[int] We can't infer the second type argument in the absence of any actual arguments. |
It's a pity we can't have |
Can we get a decision on #52427 before this is merged, to nail down the constraints package issue? |
Isn‘t only the header passed by value? Then size shouldn‘t make a difference regarding performance. |
Not the slice, the comparison function. |
Why is there a stable variant of SortFunc, but not of Sort? Edit: I think I found the answer. It's because only value types can satisfy constraints.Ordered. |
@fzipp Arguably there should be. As usually, the special case are floating point numbers, where distinguishable elements can still compare as equal. Distinguishing the stable/unstable sorting result requires using But it seems very much a corner case and people who care can then still result to For all other types satisfying |
I would have liked to hear more experience reports from people who have used this package. But maybe the silence just means they're happy so far. |
I've been using the Stats/DetailsGrepping through the source, I call:
I would have used
Looking at the API, I probably would have used APIs I haven't used and don't remember needing are One thing I've been missing a couple of times are Overall, I find myself reaching for |
Can we also add the in-place |
We could also produce a set of vet analyzers that can suggest fixes that would safely transform pre-generic code using explicit allocations/loops into calls to these new functions. |
That feels like it could get a bunch of false positives. That could be annoying if they show up in |
Sorry, I meant vet analyzer here as a shorthand for golang.org/x/tools/go/analysis analyzers, along with a standalone tool that one could apply as desired to your codebase; I didn't mean they would actually be in the vet tool. |
I think the Eventually, I think it's really natural to want backed-by-slices, generics-oriented versions of what e.g. |
This is good but what of a C++ STL equivalent, but with chain-able methods for functional programming feel |
The one function I find myself still regularly missing is the equivalent of maps.DeleteFunc. I understand why slices.Filter isn’t in the package (yet?), but an in place filter would be helpful. |
I think it will be best if suggestions for new functions in the slices package go into separate proposals. Whether or not we add new functions to the slices package does not affect whether the slices package will go into the standard library. Similarly, whether or not the slices package goes into the standard library does not affect whether we add new functions. Thanks. |
@fzipp, scanning the latest module of all publicly known modules on 2022-10-01, the usage stats are as follows:
I find it ironic that the most used function is |
|
Replace seems borderline underused for inclusion here. |
Probably a little late for this suggestion, but how about Python-style negative indexes, as in https://pkg.go.dev/github.com/bobg/go-generics/slices? |
negative indices would be a language change, most recently declined in #33359 |
Change https://go.dev/cl/467417 mentions this issue: |
@seankhliao I'm apathetic about negative indices myself, but I think he meant just for the functions in this package, not in general. Then you could do things like |
I think negative indexes at're an example of wanting to be "too clever" . It's better to use the length of the slice.
Expresses more clearly what we mean |
I just wanted to say thank you to whoever added the |
I believe it was first suggested by @rsc in #50340 (comment). |
Non-decreasing, maybe? |
This copies parts of x/exp/slices into the standard library. We omit all functions that depend on constraints.Ordered, and the Func variants of all such functions. In particular this omits the various Sort and Search functions. Fixes golang#57433 Change-Id: I3c28f4c2e6bd1e3c9ad70e120a0dd68065388f77 Reviewed-on: https://go-review.googlesource.com/c/go/+/467417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Eli Bendersky <eliben@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
Change https://go.dev/cl/492576 mentions this issue: |
#57433 added slices.Equal, using it can reduce the amount of code Change-Id: I70d14b6c4c24da641a34ed36c900d9291033f526 Reviewed-on: https://go-review.googlesource.com/c/go/+/492576 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: shuang cui <imcusg@gmail.com>
This copies parts of x/exp/slices into the standard library. We omit all functions that depend on constraints.Ordered, and the Func variants of all such functions. In particular this omits the various Sort and Search functions. Fixes golang#57433 Change-Id: I3c28f4c2e6bd1e3c9ad70e120a0dd68065388f77 Reviewed-on: https://go-review.googlesource.com/c/go/+/467417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Eli Bendersky <eliben@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
This copies parts of x/exp/slices into the standard library. We omit all functions that depend on constraints.Ordered, and the Func variants of all such functions. In particular this omits the various Sort and Search functions. Fixes golang#57433 Change-Id: I3c28f4c2e6bd1e3c9ad70e120a0dd68065388f77 Reviewed-on: https://go-review.googlesource.com/c/go/+/467417 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Eli Bendersky <eliben@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
In #45955 I proposed a new slices package in the standard library. After considerable discussion there and in discussion #47203 we settled on an API and added the experimental package golang.org/x/exp/slices.
We now have experience with this package in practice. pkg.go.dev reports that it is imported by 1,541 other packages. I propose that it is now time to move this package into the standard library for the 1.21 release.
Doing this doesn't mean that we can't add more functions to the standard library slices package later. Any such additions should be suggested in their own separate proposal.
The specific API that we will put into the standard library appears below.
This description of the API refers to
constraints.Ordered
in a few places; if the constraints package is not present in the standard library, that reference will be replaced by an unexported constraint with the same set of types.Note that we should either accept or reject #57348 before we accept this proposal. If we accept #57348, the appropriate change will be made here.
I'm not aware of any other proposal to modify the existing slices package API. There are a few proposals to add new functions to the slices package (at least #52434, #53987, #54768, #56353); those proposals can move from x/exp/slices to just plain slices.
Proposed API:
The text was updated successfully, but these errors were encountered: