proposal: x/sync/singleflight: add generic version

[bradfitz]

The singleflight package's Group type uses string keys and interface{} values:

https://pkg.go.dev/golang.org/x/sync/singleflight#Group

I've locally forked it to add generics [K comparable, V any] but I'd like to get it upstream instead.

Proposal: add singleflight.TypedGroup[K, V] or singleflight.GenericGroup[K, V] or singleflight.GroupOf[K, V] behind a go1.18 build tag.

Do we have a convention yet on naming new parallel generic types alongside others?

Related: #47657 (for PoolOf, MapOf). (There was also talk of default type parameters so old code could instantiate types and get the old behavior (in this case [string, any]) and new callers could specify types?)

[ianlancetaylor]

I don't think we have a convention yet.

[icholy]

What about x/sync/v2/singleflight ?

[catatsuy]

I tried it before. Thank you.

refs: #52520

[gopherbot]

Change https://go.dev/cl/425187 mentions this issue: all: switch singleflight to use generic

[lmittmann]

Is there any update on this proposal?

[ianlancetaylor]

@lmittmann No.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Maybe it should be x/sync/singleflight/v2.Group[K, V]? Note that even the current v0.2.0 can have a subdirectory package named v2 - it doesn't require tagging the whole repo v2.

[rsc]

This really circles back to #48287, which we didn't resolve.

[lmittmann]

I know this might sound crazy, but how about simply introducing a breaking change in an experimental package, which is v0, and has "looser compatibility requirements"?

[doggedOwl]

I agree that in this case and more generally in x/* experimental packages the right thing to do is a breaking change, eitherwise the whole purpose of these packages is mute and might as well put them directly under the standard library.

[rsc]

Holding for #48287.

[rsc]

Placed on hold.
— rsc for the proposal review group

[lmittmann]

@rsc the new discussion around math/rand/v2 (#60751) seems like there is now a consensus on how to update APIs for generics. Might this clear the way for x/sync/singleflight/v2.Group[K, V]?

[lmittmann]

Might this clear the way for x/sync/singleflight/v2.Group[K, V]?

@rsc @bradfitz have you had a chance to look into this yet?

[jmhodges]

I took a crack at the v2 formulation for this change. I've posted it as a draft because it differs enough from the original proposal that I didn't want to send it out for full review unless I heard from @bradfitz or @rsc that this was an okay way to use the original.

Happy to instead create a new proposal ticket for the v2 version of this if those folks would prefer!