On Thursday, August 25, 2016 at 5:41:32 AM UTC+8, xiio...@gmail.com wrote: > > It doesn't/wouldn't seem to be any technical issue implementing methods on > any depth of pointer type .. as demonstrated in the unsafe example linked > from a previous related discussion (ie > https://groups.google.com/forum/#!msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J > ) > > It's not allowed by the specification - and surely the (sanity) reason for > this is that if you have pointers to pointers in this context you're > probably doing something wrong/unnecessary. >
The spec never says **T values can't call methods of *T. ***T may be rarely used, but **T is not very rarely to see. > > I do get the OP's point that allowing any freedom is a great idea - and if > you want that C exists. > > Maybe there is some obscure reason or psychotic example when methods on > ****T actually has a use. > > In short - not allowed by design because dogs chasing their own tail > doesn't even help the dog. > Doesn't "not allow / break consistency" do more than "just keep consistency" in compiler implementation. -- 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.
