It didn't seem to me like proposal-killers enoguh so much so that they might not have liked some of the design choices they entailed.
The proble with the current running proposal is that it is a generalization fo what the compiler does. It definitely permits the spread of generic functions across package boundaries since they can be exported. Only that the type inference allows to not have to express the constraints in most cases. This is still a complication. What I'd like to know is what are the complexities in a package-parametrization. Indeed it would require additional syntax for package import, there would still be a problem with zero-values return. But it could be so much more simple other than that. The alternative is doing what the compiler does and dealing with constraint on kinds. Which is a bit more complex. As far as deriving constraints from code, I think that it's actually completely different at the package level than doing it at a higher granularity ( functions) because a function is not a compilation unit. It is similar to essentialy replacing a name and building the package. At the function level, I would presume that more information about the flow of data would be required. As a note, I think that with the first iteration of type aliases, people had started experimenting with such parameterization(I think in the image package). Seems a bit more intuitive. Obviously, the difference is that packages are uniquely identified by their names which is why, the names have to be internally parameterized as well. I think that dividing the design space for parametricity into simple code parametrization at the package level and type list interfaces on the other hand could be clearer and easier to handle but I'd like to know what are the pain points. On Wednesday, January 20, 2021 at 8:22:07 PM UTC+1 axel.wa...@googlemail.com wrote: > 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...@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/913e84ad-1ab7-4a9a-aa5a-656d846cc203n%40googlegroups.com.
