-
Couldn't load subscription status.
- Fork 159
x/sync/singleflight/v2: add package #23
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
base: master
Are you sure you want to change the base?
Conversation
This adds a new package, x/sync/singleflight/v2, which is a version of
x/sync/singleflight that uses generics instead of `string`, and
`interface{}` in its API.
The biggest changes are to the `Do` methods, and the `Result` type. The
`Do` methods now take a `comparable` generic type instead of `string`
for its inputs (matching that of `map` and similar). The output type of
the `Do` method and the `Val` field in `Result` are now types that user
can specify instead `interface{}`.
Along the way, some tests received modifications to remove some
now-unneeded `fmt.Sprintf` calls or add an `empty` struct for nil return
tests.
Also, `ExampleGroup` also received some additions to make it clear that
non-`string` input types are acceptable.
This is following a similar pattern as discussed with the `math/rand/v2`
project. There is, however, one difference in affordances between
packages in the stdlib and outside of the stdlib that we try to
accomadate here.
Stdlib packages like `math/rand/v2` can rely on the Go compiler version
being the one our package is released with and, for packages outside of
the stdlib, the errors can sometimes be cryptic when the package needs a
more modern Go compile than a user attempted to use.
For instance, `singleflight/v2` has a build tag specifying the need for
Go 1.18 or later to be compiled in its necessary code files. When an
older compiler is used to build it, the user will get an error starting
with "build constraints exclude all Go files in". This makes sense when
you read all of the files, but a user may be using it as a transitive
dependency and won't know whether the build tags aren't matching because
their OS is unsupported or their CPU architecture or what.
To ameliorate user confusion, an extra `notgo18.go` file has been added
with build tags saying that it's only built if the Go compiler isn't
version 1.18 or later. And that file has a compile error in it that will
error like so:
$ go1.17.2 build .
# golang.org/x/sync/singleflight/v2
./notgo18.go:16:25: undefined: REQUIRES_GO_1_18_OR_LATER
That error message is an attempt to be more clear to users about what
needs to change in their build.
Another alternative to that would be to change x/sync's `go.mod` to
require Go 1.18 or greater. However, the rest of the x/sync packages
don't require Go 1.18, and that seems like too large of a breaking
change for singleflight/v2 alone.
|
This PR (HEAD: b9dcbe5) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/sync/+/524955. Important tips:
|
|
Message from Gopher Robot: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/524955. |
|
Message from [email protected]: Patch Set 1: (2 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/524955. |
|
Message from Jeff Hodges: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/524955. |
This adds a new package, x/sync/singleflight/v2, which is a version of
x/sync/singleflight that uses generics instead of
string, andinterface{}in its API.The biggest changes are to the
Domethods, and theResulttype. TheDomethods now take acomparablegeneric type instead ofstringfor its inputs (matching that of
mapand similar). The output type ofthe
Domethod and theValfield inResultare now types that usercan specify instead
interface{}.Along the way, some tests received modifications to remove some
now-unneeded
fmt.Sprintfcalls or add anemptystruct for nil returntests.
Also,
ExampleGroupalso received some additions to make it clear thatnon-
stringinput types are acceptable.This is following a similar pattern as discussed with the
math/rand/v2project. There is, however, one difference in affordances between
packages in the stdlib and outside of the stdlib that we try to
accomadate here.
Stdlib packages like
math/rand/v2can rely on the Go compiler versionbeing the one our package is released with and, for packages outside of
the stdlib, the errors can sometimes be cryptic when the package needs a
more modern Go compile than a user attempted to use.
For instance,
singleflight/v2has a build tag specifying the need forGo 1.18 or later to be compiled in its necessary code files. When an
older compiler is used to build it, the user will get an error starting
with "build constraints exclude all Go files in". This makes sense when
you read all of the files, but a user may be using it as a transitive
dependency and won't know whether the build tags aren't matching because
their OS is unsupported or their CPU architecture or what.
To ameliorate user confusion, an extra
notgo18.gofile has been addedwith build tags saying that it's only built if the Go compiler isn't
version 1.18 or later. And that file has a compile error in it that will
error like so:
That error message is an attempt to be more clear to users about what
needs to change in their build.
Another alternative to that would be to change x/sync's
go.modtorequire Go 1.18 or greater. However, the rest of the x/sync packages
don't require Go 1.18, and that seems like too large of a breaking
change for singleflight/v2 alone.