Why a **T value can't call methods of *T and T if a *T value can call methods of T?

[T L]

.

[T L]

And why value of *I can't call methods of I? where I is an interface type.

Looks there are many inconsistencies in golang.

On Monday, August 22, 2016 at 10:04:31 PM UTC+8, T L wrote:

.

[Volker Dobler]

Because pointers to interface are almost never needed. So why complicate

the language for the sake of consistency nobody will ever notice

during the day job?

V.

[Volker Dobler]

What would it be good for?

Have you thought out all the implications?

What is wrong with the current implementation which

requires adding (* and ) . Combined by the good

error message the compiler gives you.

V.

[Dave Cheney]

Because **T and *T are different types.

[T L]

On Tuesday, August 23, 2016 at 9:07:21 AM UTC+8, Dave Cheney wrote:

Because **T and *T are different types.

*T and T are also different types.
What treat **T and *T differently?

[T L]

On Monday, August 22, 2016 at 11:28:54 PM UTC+8, Volker Dobler wrote:

Because pointers to interface are almost never needed. So why complicate

the language for the sake of consistency nobody will ever notice

during the day job?

Just for a better consistency.

Pointers to interface are not useless totally.
Many std libs need pointers to interface.
 

[Jesse McNelis]

> Why a **T value can't call methods of *T and T if a *T value can call methods of T?

How many levels of auto dereferencing should there be?
Should *************T still have the same method set as *T?

It's reasonable to set a sensible limit because pointer chasing is an
expensive operation.
So for anything more indirect than *T you need to explicitly show the
dereferencing.

[Volker Dobler]

Am Dienstag, 23. August 2016 04:58:31 UTC+2 schrieb T L:

On Monday, August 22, 2016 at 11:28:54 PM UTC+8, Volker Dobler wrote:

Because pointers to interface are almost never needed. So why complicate

the language for the sake of consistency nobody will ever notice

during the day job?

Just for a better consistency.

Consistency is no end in itself.

V. 

[T L]

On Tuesday, August 23, 2016 at 11:28:55 AM UTC+8, Jesse McNelis wrote:

> Why a **T value can't call methods of *T and T if a *T value can call methods of T?

How many levels of auto dereferencing should there be?
Should *************T still have the same method set as *T?

If a programmer will call it anyway, she/he doesn't care efficiency. What she/he cares is the convenience and cleanness.
ppppppt.f() is surely cleaner than (*****ppppppt).f(), right?

[T L]

I think the rule is quite simple, the method set of *T is a superset of the method set of T.
This should also true if T is already a pointer type.
 

V. 

[Jesse McNelis]

On Tue, Aug 23, 2016 at 3:11 PM, T L <tapi...@gmail.com> wrote:
> If a programmer will call it anyway, she/he doesn't care efficiency. What
> she/he cares is the convenience and cleanness.
> ppppppt.f() is surely cleaner than (*****ppppppt).f(), right?
>

It shouldn't be convenient or look clean to do the wrong thing.
(*****ppppppt).f() should look horrible because it is horrible.

[T L]

 rules should be broken for horrible.

[T L]

Looks this question can be stated as "why can't named pointer types have methods?"

package main

type PT *int
func (pt PT) f() {} // error: invalid receiver type PT (PT is a pointer type)

func main() {}

[Dan Kortschak]

Ian has an answer for this here
https://groups.google.com/d/msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J

[T L]

On Tuesday, August 23, 2016 at 1:28:03 PM UTC+8, T L wrote:

Looks this question can be stated as "why can't named pointer types have methods?"

Just found this thread https://groups.google.com/forum/#!topic/golang-nuts/Vhh5XOm96YI
to answer "why can't named pointer types have methods?"

But I think the two questions are not totally equivalent:
1. Why a **T value can't call methods of *T?
2. Why can't named pointer types have methods?
 

[T L]

On Tuesday, August 23, 2016 at 1:35:16 PM UTC+8, kortschak wrote:

Ian has an answer for this here
https://groups.google.com/d/msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J

the two questions are not totally equivalent.
 

[Dan Kortschak]

It's the answer to the question you have below.

[Ian Lance Taylor]

On Mon, Aug 22, 2016 at 10:37 PM, T L <tapi...@gmail.com> wrote:
>
> On Tuesday, August 23, 2016 at 1:28:03 PM UTC+8, T L wrote:
>>
>> Looks this question can be stated as "why can't named pointer types have
>> methods?"
>
>
> Just found this thread
> https://groups.google.com/forum/#!topic/golang-nuts/Vhh5XOm96YI
> to answer "why can't named pointer types have methods?"
>
> But I think the two questions are not totally equivalent:
> 1. Why a **T value can't call methods of *T?
> 2. Why can't named pointer types have methods?

Your second question has been answered.

The first question is, essentially, what is the method set of **T?
The answer is: **T has no methods. Why should it?

T has methods (or at least may have methods): the methods whose
receiver is type T. *T has methods: the methods whose receiver is
type *T. For convenience, the methods of T are added to the method
set of *T.

**T does not have methods. There is no reason to add the methods of
*T to the method set of **T, because the method set of **T is empty.

Ian

[T L]

ok, we know golang doesn't lack minor/exception rules.
 

Ian

[xiio...@gmail.com]

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.

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.

[T L]

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.
 

[T L]

On Thursday, August 25, 2016 at 5:41:32 AM UTC+8, xiio...@gmail.com wrote:

does "dogs chasing their own tail" do any harm?

 

[xiio...@gmail.com]

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

?

[xiio...@gmail.com]

[edit] Just retracting the statement "if you have pointers to pointers in this context you're probably doing something wrong/unnecessary." I made earlier - which is clearly wrong on a moments thought. 

Sorry..

[Ian Lance Taylor]

On Thu, Aug 25, 2016 at 3:09 AM, T L <tapi...@gmail.com> wrote:
>
> 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.

There is, of course, no reason for the spec to say that.

The spec defines method sets for types. A type **T can never have any methods.

Ian

[T L]

They are the same.
 

[xiio...@gmail.com]

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.

[T L]

ok, I prefer the first one: ***T has methods of ***T, **T, *T, T.