Most of the remaining constraints after #48424 are purely numeric: Complex, Float, Integer, Signed, Unsigned. They can all just be added to package math. Ordered is the exception because it also involves strings. It can be added to package sort. There's no longer any need for a top level constraints package.
The text was updated successfully, but these errors were encountered:
I'm not sure that math.Integer or sort.Ordered convey quite the right feel. They don't sound like constraints.
Conversely, as I mentioned in #45458 (comment), constraints might not always remain only constraints. Committing to names like constraints.Float instead of math.Float could make the future more awkward.
I think this is a good one to avoid the lengthy constraints to appear in the function signature.
I have been experimenting with roughly the same idea that uses self-defined math.Float to replace constraints.Float (also intended to avoid import x/exp/constraints just for a simple interface definition). My overall feeling on the usage of math.Float is positive. See how the usage is distributed in a math package.
The key questions: do we really need a centralized place to define "all" constraints? or how many constraints are expected to appear but not yet in x/exp/constraints?
One addition but less problematic: the dependencies of math and sort won't be able to use these constraints (i.e. math/bits and runtime), but they can also define these constraints internally to avoid circular import easily.
Perhaps it's a coincidence that the current constaints can be considered for the math package? Other future constaints might not have a convient pre-existing package to slot them into. There might be a need for the remainder to fit into a separate "constraints" package again?
This is hypothetical, but it's hard to predict where type parameters and constraints will evolve over time - developers have only started exploring this space.
Is this mostly a workaround for constraints being too long? (I don't think that is a good reason). Or do people think merging into existing packages is more appropriate for a reason outside package name length?
The main problem with a constraints package is that is is very likely to become a dependency of all generic packages, even though it doesn't have any functionality, only types. But "a little copying is better than a little dependency", so it is probably better for each generic package to define its own constraints.
@beoran It would be interesting to see how many packages that use generics do in fact import constraints. I would be surprised if most do. I checked some packages in Google internal code that define generics, and none of them import constraints.