RFC: int vs uint for Choice.Weight

[mroth]

Currently, Choice is defined such that:

type Choice struct {
    Item   interface{}
    Weight uint
}

My original intention here was from he "make invalid states unrepresentable" perspective -- and negative weights could cause errors, however #4 will introduce safety checks at creation time in NewChooser, making this less necessary.

However, it is potentially more idiomatic to utilize an int here, since it tends to be the numeric value type most commonly used by the Go community. The definition would then change slightly such that any Choice with Weight <= 0 would represent something that would never be selected. This could avoid potential typecasting (an ergonomics issue, not relevant to performance) when creating new Choices.

There are primary downside I can think of:

• This would be another breaking API change, but since we will be pushing those anyhow in the next semver release due to #4, now is the right time to consider it.
• The running total algorithm used in a Chooser relies on all weights being >= 0, while zero values are fine, negative values will cause state corruption during initialization. This could be easily handled by having NewChooser simply skip any items with weight <= 0 and not insert them in the internal data table at all. This is still fine from a behavior perspective, since they can never be selected by a Pick, however it would mean that we could likely not have options in the future to enumerate all items in a Chooser, or specify that the enumeration would only reflect selectable items. This does not seem to be a likely needed use case anyhow, however.

I'm currently mildly in favor of making this change now from an ergonomics perspective to hone in on the best API before stabilizing this library, but would love feedback from users. Otherwise it's probably not worth the disruption unless it's really better for users.

[mroth]

@0xERR0R do you have an opinion on this, by chance?

[0xERR0R]

@mroth thanks for asking for my opinion ;) Well, from my point of view, a negative weight doesn't make sense. Of course, you can handle negative values as 0, but there is a chance, that somebody can misunderstand your API. I would prefer clear interface: weight is always positive and therefor it is absolutely ok to use an uint. I'm aware of this "ideomatic" stuff in golang, but just IMHO it is not always the best way to solve problems.

[mroth]

Going to stick with uint for now!