It is implicit: the functions defined in the contract are available (in scope) in generic functions that use the contract.
I’m thinking about revising how the adaptors work. I might let contracts act as adaptors. But I don’t have time to work on it any more today. Andy > On Nov 5, 2018, at 7:59 PM, Lucio <lucio.d...@gmail.com> wrote: > > The word "elegant" comes to mind... Comments below. > > On Monday, 5 November 2018 21:47:46 UTC+2, Andy Balholm wrote: > The concept of using operators to implement methods cross-pollinated in my > mind with Patrick’s “Go Generics with Adaptors” thought experiment and > produced this: > https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 > <https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890> > > Here is the core of the proposal (the gist of the gist?): > > Contracts > > In this proposal, a contract is a list of type-specific functions that are > needed to implement a generic algorithm. Generally, it will contain default > implementations for these functions, but these are optional. (If default > implementations are not included, an adapter will always be necessary.) The > default implementations are unconstrained generic code; if they compile > successfully with a given set of type parameters, those parameters fulfill > the contract. > > contract Adder(T) { > Zero() T { > return 0 > } > Add(a, b T) T { > return a + b > } > } > A generic function that uses a contract calls the functions in the contract > to perform operations on generic values: > > func SumSlice(type T Adder)(s []T) T { > sum := Zero() > for _, t := range s { > sum = Add(sum, t) > } > return sum > } > I see that in the proposal (nice and short) you imply a relationship between > the function invocation and the contract. Is it really implicit (it isn't to > my sleep-addled brain) that Zero within SumSlice is restricted by contract > Adder, simply because its argument is of type "type T Adder"? I would think > that invoking Adder.Zero() or even T.Zero() would be necessary or at least > more explicit? > > In other respects, I doff my hat to you, Andy :-). > > The rest of your document (the crucial "adaptors") I still need to assimilate. > > Lucio. > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
