On Fri, Jul 17, 2020 at 1:56 AM Markus Heukelom
<markus.heuke...@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/CAOyqgcVVNwuQDpzw9U2RsWDmZHGn3kjBksr-fDdUtgssA5WgpA%40mail.gmail.com.
