generic function with a pointer parameter

[Manlio Perillo]

Consider this example, adapted from https://github.com/golang/proposal/blob/master/design/43651-type-parameters.md#composite-types-in-constraints (note that the example is incorrect):

https://gotipplay.golang.org/p/a8fHVTUpeie

The compiler reports an error:

./prog.go:14:9: p.x undefined (type *T is pointer to type parameter, not type parameter) ./prog.go:16:4: p.x undefined (type *T is pointer to type parameter, not type parameter)

What is the reason why the code does not compile?

Thanks

Manlio

[Jan Mercl]

On Thu, Jan 27, 2022 at 11:42 AM Manlio Perillo
<manlio....@gmail.com> wrote:

> What is the reason why the code does not compile?

I cannot answer your question, but just noting that this compiles and
executes fine: https://gotipplay.golang.org/p/wveI2JzIxSr

[Manlio Perillo]

Here is an alternate implementation:

https://gotipplay.golang.org/p/mGm8DkqkuAX

The code **seems** reasonable, but the compiler reports an error:

./prog.go:24:12: *MyStruct does not implement structField

Thanks

 Manlio

[Clem Clem]

Hello

Check this

https://gotipplay.golang.org/p/d7nq2OV82Nv

[Manlio Perillo]

In your implementation, p type is no longer generic.

Manlio

[Ian Lance Taylor]

It probably should and eventually will compile. There are a lot of
corner cases about structural constraints. Do not expect them all to
be sorted out in the 1.18 release.

Is there any practical use for this or are you just curious?

Ian

[Ian Lance Taylor]

I believe that that error message is correct. The constraint is for
any type whose underlying type is "*struct{ x int }". The code is
trying to instantiate with the type *MyStruct. The underlying type of
*MyStruct is *MyStruct. It is not *struct{ x int }. So the type
argument does not match the constraint.

Ian

[Manlio Perillo]

On Thu, Jan 27, 2022 at 9:57 PM Ian Lance Taylor <ia...@golang.org> wrote:
>
> On Thu, Jan 27, 2022 at 2:42 AM Manlio Perillo <manlio....@gmail.com> wrote:
> >
> > Consider this example, adapted from https://github.com/golang/proposal/blob/master/design/43651-type-parameters.md#composite-types-in-constraints (note that the example is incorrect):
> > https://gotipplay.golang.org/p/a8fHVTUpeie

> [...]

>
> Is there any practical use for this or are you just curious?
>

I'm just curious.

Thanks
Manlio

[Manlio Perillo]

On Thu, Jan 27, 2022 at 10:00 PM Ian Lance Taylor <ia...@golang.org> wrote:
>
> On Thu, Jan 27, 2022 at 3:13 AM Manlio Perillo <manlio....@gmail.com> wrote:
> >
> > On Thursday, January 27, 2022 at 11:42:19 AM UTC+1 Manlio Perillo wrote:

> [...]

> > Here is an alternate implementation:
> > https://gotipplay.golang.org/p/mGm8DkqkuAX
> >
> > The code **seems** reasonable, but the compiler reports an error:
> > ./prog.go:24:12: *MyStruct does not implement structField
>
> I believe that that error message is correct. The constraint is for
> any type whose underlying type is "*struct{ x int }". The code is
> trying to instantiate with the type *MyStruct. The underlying type of
> *MyStruct is *MyStruct. It is not *struct{ x int }. So the type
> argument does not match the constraint.
>

However (from the first example) MyStruct matches struct {x int }.
It seems a bit confusing that *MyStruct does not match *struct {x int }.

Thanks
Manlio

[Ian Lance Taylor]

I do understand the confusion. Still, the rule for a constraint like
"~*struct{ x int }" is that the underlying type of the type argument
must be "*struct{ x int }". It's not reduce each type in the type
argument to its underlying type and see if you wind up with "*struct {
x int }"." We want to be precise here.

Ian

[Manlio Perillo]

Thanks for the explanation.

Is it possible to add this case as an example in the design document?

I'm also not sure if this is related to https://tip.golang.org/ref/spec#Underlying_types or to golang.org/design/43651-type-parameters#type-unification.

Manlio