Re: named pointer type: invalid receiver type

[Han-Wen Nienhuys]

Why is it not allowed to define pointer types as named types with methods?

It is possible to fake this using unsafe.Pointer (see
http://play.golang.org/p/Iz35o8mqdy ), so I wonder why.

(Background: I was trying to see if I coulud cover up some of my API
mistakes in the SSH package by defining the NewChannel and Channel
types as pointers rather than interfaces)

--

Google Germany GmbH, Dienerstrasse 12, 80331 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

[Chris Manghane]

From http://golang.org/ref/spec#Method_declarations:
"The type denoted by T is called the receiver base type; it must not be a pointer or interface type and it must be declared in the same package as the method."

I'm not sure what you're trying to do here, but it seems like you could accomplish it by making `type pt int` and then defining f on the pointer receiver *pt. That seems like the same thing as defining a receiver type as a pointer type with its methods.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Han-Wen Nienhuys]

n

On Tue, Jun 9, 2015 at 3:25 PM, Chris Manghane <cm...@google.com> wrote:
> From http://golang.org/ref/spec#Method_declarations:
> "The type denoted by T is called the receiver base type; it must not be a
> pointer or interface type and it must be declared in the same package as the
> method."

Sure, I found that reference. I'm curious *why* pointers are forbidden.

> I'm not sure what you're trying to do here, but it seems like you could
> accomplish it by making `type pt int` and then defining f on the pointer
> receiver *pt. That seems like the same thing as defining a receiver type as
> a pointer type with its methods.

I have code that looks like

type Channel interface { .. }
func New() Channel { .. }

In this case, the Channel isn't really an interface (there is only one
implementation of it), and suggests that we will never add new methods
to the type. If I could convert this to

type Channel *impl
func New() Channel { .. }

then this gives us more freedom for adding methods to Channel, without
breaking the bulk of the existing callers. By contrast, saying

type Channel struct { .. }
func New() *Channel

will break type declarations in callers of the API.

I realize aliasing Channel to a poniter may not be desirable for other
reasons, but that is beside the point here.

> On Tue, Jun 9, 2015 at 3:02 AM 'Han-Wen Nienhuys' via golang-nuts
> <golan...@googlegroups.com> wrote:
>>
>> Why is it not allowed to define pointer types as named types with methods?
>>
>> It is possible to fake this using unsafe.Pointer (see
>> http://play.golang.org/p/Iz35o8mqdy ), so I wonder why.
>>
>> (Background: I was trying to see if I coulud cover up some of my API
>> mistakes in the SSH package by defining the NewChannel and Channel
>> types as pointers rather than interfaces)
>>
>> --
>>
>> Google Germany GmbH, Dienerstrasse 12, 80331 Munich
>>
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> Sitz der Gesellschaft: Hamburg
>>
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>>
>> --
>> 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...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

--
Han-Wen Nienhuys
Google Munich
han...@google.com

[Ian Lance Taylor]

On Tue, Jun 9, 2015 at 3:01 AM, 'Han-Wen Nienhuys' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> Why is it not allowed to define pointer types as named types with methods?

Because in a case like this:

type I int
type P *I
func (i I) Get() int { return int(i) }
func (p P) Get() int { return int(*p) }
var v I
var x = (&v).Get()

it would be unclear whether the Get method in the last line would be
I.Get or P.Get. We could define a rule for it, but that would become
another thing that people would have to know.

Ian