Hello, It' has probably been discussed somewhere but I am curious about what might have been the issues when considering an implementation of generics that would parameterized packages?
The rationale being that usually, packages have a non-mutable interface for the user and are the ompilation unit if I'm not mistaken. So why not just relax the interface exposed by a package and allow for package-wide type specialization? In terms of pure parametric polymorphism, having packages with a mutable interface in terms of types (via mutation of type aliases for instance) would just be the next iteration. It may require a little bit more from the build tool but the type checking would not have to change I think. The constraints on the parameter would stem implicitly from the code within a package in terms of operations used and interfaces being implemented. I would expect such "parameterized" packages to be rare, non-pervasive if not for the simple fact that most parameterized package would mostly be able to import other generic packages since they would be defined with abstract types. The compiler may still want to insure that the constraints make sense throughout the dependency tree of generic imports incrementally but I don't think that that would be a huge problem. I think that it could be something orthogonal to the design of type constraintd, notably type Lists, that are anyway highly desirable imo but more so to constrain interfaces to a finite set of types ( as a way to have union types, enums, sumtypes or whatnot). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4a7b128c-abaf-4399-a19b-657f9cf1443bn%40googlegroups.com.
