Thanks for the answer.
Concerning only the current proposal, is there a reason why we shouldn't
allow specifying the parametric types for a whole bunch of functions /
types at once?
Like:
generic (type T) (
func Average(value []T) {...}
func Median(value []T) {...}
// etc
)
generic (type T1, T2) (
func Map(s []T1, func(T1) T2) []T2
func BiMap(s []T1, func(T1) T2) []T2
//...
)
All things within generic () would have the same type parameter signature.
It would be a bit similar to how var and const declarations work. It would
remove a lot of redundancy and parenthesis.
To make things symmetric, a single generic function would have to be
specified with something like this
generic (type T1, T2) func Map(s []T1, func(T1) T2) []T2.
type Vertex generic (type T) struct {
Coords [3]T
}
On Fri, Jul 17, 2020 at 8:26 PM Ian Lance Taylor <i...@golang.org> wrote:
> 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/CAMoB8rVSU%2B1vbrZ9QiUjs7vBc4KbiddiaKyvv3b1M4TXb%3DL58w%40mail.gmail.com.
