proposal: sync/v2: new package

### Proposal Details The math/rand/v2 package has been successful. Let's consider another v2 package: sync/v2. This is an update of #47657. ### Background The current sync package provides `Map` and `Pool` types. These types were designed before Go supported generics. They work with values of type `any`. Using `any` is not compile-time-type-safe. Nothing prevents using a key or value of any arbitrary type with a `sync.Map`. Nothing prevents storing a value of any arbitrary type into a `sync.Pool`. Go is in general a type-safe language. For all the reasons why Go map and slice types define the their key and element types, `sync.Map` and `sync.Pool` should as well. Also, using `any` is inefficient. Converting a non-pointer value to `any` requires a memory allocation. This means that building a `sync.Map` with a key type of `string` requires an extra allocation for every value stored in the map. Storing a slice type in a `sync.Pool` requires an extra allocation. These issues are easily avoided by changing `sync.Map` and `sync.Pool` to be generic types. While we can't change `Map` and `Pool` to be generic in the current sync package because of compatibility concerns (see the discussion at #48287), we could consider adding new generic types to the existing sync package, as proposed at #47657. However, that will leave us with a confusing wart in the sync package that we can never remove. Having both `sync.Pool` and (say) `sync.PoolOf` is confusing. Deprecating `sync.Pool` s

Posted by ianlancetaylor on Jan 1, 2025, 2:32 AM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0