My five cents:
1) the methods of the type template are defined by interface style
2) operators are retrieved implicitly from function body
3) function-calls inside are also retrieved implicitly from the function
body
For graph example, we may declare it as:
type Edgeser(type E) interface {
Edges() []T
}
type Nodeser(type N} interface {
Nodes() from, to N
}
type Graph(type Node Edgers(Edge), type Edge Nodeser(Node)) struct { ... }
On Monday, September 3, 2018 at 4:19:59 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts
> <golan...@googlegroups.com <javascript:>> wrote:
> >
> > Link: [Getting specific about generics, by Emily
> > Maier](https://emilymaier.net/words/getting-specific-about-generics/)
> >
> > The interface-based alternative to contracts seems like such a natural
> fit-
> > It’s simple, straightforward, and pragmatic. I value those aspects of
> Go’s
> > philosophy and consider them to be features of the language, so it’s
> > encouraging to see a solution that suits them so well. The author also
> does
> > a great job of contextualizing the use cases and debate around generics,
> > which I found incredibly helpful.
> >
> > Any thoughts?
>
> It's a very nice writeup.
>
> It's worth asking how the graph example in the design draft would be
> implemented in an interface-based implementation. Also the syntactic
> issues are real.
>
> 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.
For more options, visit https://groups.google.com/d/optout.
