On Saturday, August 27, 2016 at 3:22:04 AM UTC+8, xiio...@gmail.com wrote: > > > > On Friday, 26 August 2016 16:32:47 UTC+1, T L wrote: >> >> >> >> On Thursday, August 25, 2016 at 9:30:01 PM UTC+8, xiio...@gmail.com >> wrote: >>> >>> I get the original points. Though the current behaviour is in my opinion >>> consistent with https://golang.org/ref/spec#Method_declarations >>> "[Receiver] must be of the form T or *T (possibly using parentheses) where >>> T is a type name" and https://golang.org/ref/spec#Method_sets I can see >>> the case for extending methods to include any depth of indirection. >>> >>> Though I've never had a use case for methods on **T, it's clear that **T >>> 's can have real uses. >>> >>> If a language extension was requested, which behaviour would you prefer >>> for the method sets >>> >>> ie >>> >>> ***T has methods of ***T, **T, *T, T >>> or >>> ***T has methods of just ***T and **T >>> ? >>> >> >> They are the same. >> >> > > No they are not the same > > Take the examples literally, do not expect recursive additions of method > sets. > > The language specification https://golang.org/ref/spec states the > difference between "methods" and "method sets" > > I specifically said "methods", not "method sets" in the example. > > ok, I prefer the first one: ***T has methods of ***T, **T, *T, T.
-- 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.