On Tue, Jul 21, 2020 at 5:53 AM Manlio Perillo <manlio.peri...@gmail.com> wrote: > > What about: > > package example(T1, T2) > > This declares T1 and T2 as package level types. > > import "example"(int, float) > > This imports the example package with T1 as int and T2 as float. > > The limitation is that you need to import the same package multiple times for > different T1 and T2.
What about list(list(int))? If we have to import a package, and then use a type from that package, and then import another package, well, that's fairly different from how Go works today. Ian > Il giorno venerdì 17 luglio 2020 alle 20:26:42 UTC+2 Ian Lance Taylor ha > scritto: >> >> On Fri, Jul 17, 2020 at 1:56 AM Markus Heukelom >> <markus....@gain.pro> wrote: >> > >> > The authors of the current generics proposal mention that they looked into >> > doing generics only on package >> > level:(https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages) >> > >> > I understand the reasons what it wasn't pursued further. >> > >> > Did the authors investigate the possibility of declaring generic types on >> > a package level instead of per type/function? Ie. >> > >> > generic T {} >> > >> > func Max(a, b T) T {} >> > func Min(a, b T) T {} >> > >> > I wrote down an idea on this, that is admittingly a bit wild (or naive) or >> > maybe impossible from a parsing perspective. But I'd like to validate the >> > main idea behind it. >> > >> > My whole attempt was based on the observation that most packages that will >> > include generic functionality, will only really need one or maybe a couple >> > of generic type constraints. >> > >> > For example, if you look at a hypothetical statistics package, there will >> > be many, many functions that compute stuff on slices of T, where T must be >> > a number. So there will be many functions like: >> > >> > type Number interface { // using currently proposed generics >> > type int, float64, // etc >> > } >> > >> > func Average(type T Number)(values T...) T {} // using currently proposed >> > generics >> > func Median(type T Number)(values T...) T {} >> > func Binonimal(type T Number)(values T...) T {} >> > // etc etc etc >> > >> > My point is that the "(type T Number)" part in all the declarations / >> > definitions become really redundant from a human perspective, just because >> > a package will naturally (should?) only use 1 or at most a couple of >> > generic types. That would make it, at least theoretically, possible to >> > write something like >> > >> > type Number interface { >> > int, float64, // etc >> > } >> > generic T Number >> > >> > func Average(values T...) T {} >> > func Median((values T...) T {} >> > // etc >> > >> > Coincidentally, the builtin language sort of uses this idea in its >> > documentation. >> > >> > Another (theoretic) possibility would be something like this: >> > >> > generic T Number ( // analog to multiple const or var declarations >> > func Average(values T...) T {} >> > func Median((values T...) T {} >> > ) >> > >> > My question is: did the authors investigate something like this, or is it >> > plainly impossible or undesired? >> > >> > For those interested, my proposal can be found here: >> > https://github.com/golang/go/issues/39716. I use the key word "meta" there >> > instead of "generic". >> >> Thanks for the note. >> >> Yes, we looked at ideas like that. It's unclear how to handle this >> area at the point where we want to instantiate the generic function or >> type. How do we pass the type argument? If there is a single generic >> type parameter it's not so bad, but there are many simple examples >> that require multiple type parameters, such as the Map function on >> slices: >> >> func Map(type T1, T2)(s []T1, func(T1) T2) []T2 >> >> There should be some natural way for the caller to write Map(int, >> string) to get a value whose type is >> >> func([]int, func(int) string) []string >> >> If generics are defined at the package level, how do we do that? >> >> If the answer is that you specify the type arguments when you import >> the package, then how do handle List(List(int))? >> >> 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/40412f47-678d-4850-8344-97d86a964e42n%40googlegroups.com. -- 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/CAOyqgcVpDdY9QVbjmMEMYRJhre2t9wpm%3DRhV%2BuLWzQdd6EVmQg%40mail.gmail.com.
