It does mention it but I fail to see the problem specifically. I am curious about anything that would make it a proposal-killer in terms of design for Go. Also, the distinction I see is that it would not be the same instantiation of the same package as much as the creation of new packages ( the package names should be parameterized too depending on the input) As such, packages could be cached and reused for the same input parameters. Having different packages for different kinds seems to be a good separation of concerns to me. Quite the opposite from mixing package boundaries with types, I think it's rather the opposite. (the oppsoite being to allow generic functions spreading across package boundaries) Besides, that's exactly what would happen if we had to do it by hand as of today or via code-generation. Hence, we get type specialization trivially.
For instance, if we take the List counter-example, I understand that higher kind polymorphism allow to have only one function definition, albeit parameterized, but it's more complex to write (constraints) and it may allow a pervasive use of generics that may not be conducive to simple go code. (Namely, the introduction of the functional patterns such as map/transform/reduce. (which is nothing but an abstraction... nice for people who appreciate it but not necessarily as a generic function imo)) The rest of use-cases for generics could be handled with interfaces and/or the introduction of type-lists, enabling union/sumtypes, essentially augmenting the concept of interface types. On Wednesday, January 20, 2021 at 6:21:10 PM UTC+1 jake...@gmail.com wrote: > If I understand correctly, this question is specifically addressed by the > design draft: > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages > > On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com > wrote: > >> 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/7ba98154-ecee-4657-9985-ce21a80c68c2n%40googlegroups.com.
