The proposal-killers are mentioned - it is awkward for different instantiations of the same package to interact and there is no reason to believe generic usecases will delineate neatly into packages. It sounds like you do not agree that those are proposal-killers. And of course, you are welcome to write down your own design and maybe you even see something they didn't see. But you should be prepared that ultimately, in a "agree to disagree" situation, if the Go team feels it is awkward, their opinion will be what tips the scales.
On Wed, Jan 20, 2021 at 7:09 PM atd...@gmail.com <atd...@gmail.com> wrote: > 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) > Just to point out the obvious, that this means you still have to make up a syntax for type-parameters and instantiations. So, this is not a simple matter of importing a regular package. 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) > Generic functions do not spread across package boundaries. Every generic function and every generic type will still live in a single package. > it's more complex to write (constraints) > FTR, the way to express constraints is largely independent on whether you constrain types on a per-function/type or per-package level. For example, you suggested constraints should be derived implicitly based on the operations used in the package. But you can do that with generic functions too. For example, a previous incarnation of the generics design <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md> would have allowed you to specify constraints by writing a function body using all operations you need. In particular, you could've used the function body itself as a contract. So if you take that design and just declare that the contract of a generic function is *implicitly* its function body, you'd get your idea of "constraint-less generics", while operating entirely on a per-function level. That previous incarnation was abandoned though, because it turns out that implicitly deriving constraints from code is just surprisingly complicated, opens up more questions than it answers and - in my opinion at least - just generally a very bad idea. So, I'm not too optimistic about a new proposal, that tries to go back to that approach. In any case. As I said, my goal isn't really to convince you that your approach won't work - just to explain why I don't think your approach is likely to get accepted. (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 > <https://groups.google.com/d/msgid/golang-nuts/7ba98154-ecee-4657-9985-ce21a80c68c2n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfEJoHNiiQFMAfRiGRhp2E8GC4HhCNz9uSpPwY%3DKOuL7LQ%40mail.gmail.com.
