On Tuesday, September 4, 2018 at 9:52:07 AM UTC-7, xingtao zhao wrote:
>
> 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
>
There is no need for 3). We only need to check if the parameter types
satisfy the constraint for the functions that are called inside.
>
> 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
>> <[email protected]> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
