Exploratory work towards a potential v3 release

[mroth]

Key breaking changes would include (TBD list in progress):

• Migration to rely upon math/rand/v2, exposing a different surface area for custom randomness sources (see Nit: undeprecate PickSource #29)

Non-breaking changes:

• Change backing of Chooser to be uint64, no API changes but more easily implemented with the math/rand/v2 migration. (addresses Use of int for internal counter #31)

[trungdlp-wolffun]

I'm very excited to improve. Can I help you, @mroth?

[mroth]

I'm very excited to improve. Can I help you, @mroth?

That'd be great! Now that Go 1.23 is released, mostly what remains here is validating the new method for setting a custom randomness source, seen in cd42f24. I'm still not sure about the API here.

[robinjoseph08]

As a user of v2, I think the API looks good here. As a bonus, it would be nice to rename your NewChooser function to NewChooserWithRand and then make a new simple NewChooser function that just calls NewChooserWithRand with nil as the passed in rand value. I think most people's use-cases will be wanting to set the rand at instantiation, and while you can do it with

c, _ := weightedrand.NewChooser(...)
c.SetRand(r)

it's more convenient to do it all in a single call.

If you're on the fence about including the SetRand method altogether, I personally don't have a major use for it, though I could see it being useful for testing purposes (i.e. swapping out the rand source for each test so that various cases can be tested). Maybe you can leave it off for the first version of v3 (assuming you add the NewChooserWithRand function), and if you get requests for it, you can easily add it back in? It's harder to deprecate/remove functionality than to add it.

Other than that, it all seems reasonable to me, and I'm excited for when it's released!

[mroth]

As a user of v2, I think the API looks good here.

Thank you for the helpful and thoughtful feedback @robinjoseph08 ! Sorry for the delay in response.

...it would be nice to rename your NewChooser function to NewChooserWithRand and then make a new simple NewChooser function that just calls NewChooserWithRand with nil as the passed in rand value. I think most people's use-cases will be wanting to set the rand at instantiation...

Yeah, I can see that. My worry with the ergonomics is that since NewChooser takes Choices as variadic args (perhaps not the best in retrospect, but I don't know if I should change that at this point), the rand source would have to come first in ordering, and its a bit confusing from an idiomatic perspective to have the "option" come first in the parameter ordering. The alternative would be to have a fairly different signature for NewChooserWithRand entirely, e.g.:

// generic type constraints omitted in examples here to aid in clarity of readability:
func NewChooser(choices ...Choice) (*Chooser, error)
func NewChooserWithRand(choices []Choice, r *rand.Rand) (*Chooser, error)

But this presents other ergonomics issues due to the inconsistency (and I generally do think its better to avoid requiring slice construction in the call site, so end-users to not have to deal with declaring []Choice[T, W]{...} in the callsite.

A third alternative could be to offer a chainable func (c *Chooser) WithRand(r *rand.Rand) *Chooser (or perhaps a WithOptions(opts ...ChooserOption) for future proofing), making this settable at instantiation. This could also be introduced in the future.

If you're on the fence about including the SetRand method altogether, I personally don't have a major use for it, though I could see it being useful for testing purposes (i.e. swapping out the rand source for each test so that various cases can be tested). Maybe you can leave it off for the first version of v3 (assuming you add the NewChooserWithRand function), and if you get requests for it, you can easily add it back in? It's harder to deprecate/remove functionality than to add it.

Good points all. I was hoping to reintroduce some way to do this in v3 (due to requests in #29), but this is currently the design decision that is blocking getting to a release...