On Wed, Jan 20, 2021 at 11:42 AM atd...@gmail.com <atd...@gmail.com> wrote: > > > 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.
I think Axel has expressed the pain points pretty well. You've got a List package that lets you manage linked lists of some type. So you write import listint "list[int]" and then you can write lst := listint.New(); lst.Push(1). Or something like that. Now you want a list of lists of int. How do you write that? import listint "list[int]" import listlistint "list[listint.List]" ? That is not how imports work in Go. Now import has changed from "import a package" to "instantiate an imported package". Those are pretty different operations. Also look at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform and think about how to implement that using generic packages. More generally, there just isn't any clear reason to believe that generic types and functions naturally map to package boundaries. It's easy to think up cases where I would want an unexported generic function. If only packages can be generic, then I have to create a new internal package just to represent that function. That seems tedious. You have asked a couple of times for "proposal-killers". I'm not sure that there are proposal-killers for attaching generics to packages. I think it could probably be made to work. In 2017 Robert Griesemer and I spent about six months working up a generic proposal based on packages. But in the end we stopped pursuing that approach, because there were too many difficulties and awkwardnesses. Ian -- 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/CAOyqgcUUo%3Dgc2OT%2Be4O-h0-midr5U-Nhzmideqod2a7q3vqmqA%40mail.gmail.com.
