might be a hole in Golang specification regarding the definition of "addressable"

[王旭东]

Hi, I have a question about "addressable."

The following code illustrates my question (see the comments):
https://go.dev/play/p/xpiPXuEqh0O?v=gotip

I also posted question in the Gopher Slack channel, and @Axel Wagner provided a detailed explanation, suggesting that this might be a gap in the Go specification.
@Jason Phillips recommended that I ask this question in the GitHub issues and the golang-nuts mailing list.

I really appreciate everyone’s help mentioned, but I still don’t have a clear conclusion.

To simplify: my question is why the result of myfunReturnPointer() is addressable if we strictly follow the specification.

Thanks,

Xudong

Jason Phillips

[Ian Lance Taylor]

In https://go.dev/ref/spec#Selectors the spec explains that if the
type of x is a pointer, then the selector expression x.f is shorthand
for (*x).f. That is the case in your playground example: the
expression myfunReturnPointer().i is short for
(*myfunReturnPointer()).i. The pointer indirection
*myfunReturnPointer() is addressable according to
https://go.dev/ref/spec#Address_operators. So this is a field
selector of an addressable struct operand.

Ian

[Axel Wagner]

Oh, I only just realized that "pointer indirection" is literally in that list of addressable things. For some reason I have overlooked that, even after re-reading the section of the spec several times. That really makes this clear.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUL0D9a0nmXP%2BNJTPrax-ixWFUvRwuUAK5m1G-LtjzH7w%40mail.gmail.com.

[王旭东]

Hi Ian, Axel (Glad to see you here;-)

Thank you for your quick explanation.

However, I would like to point out that selector rule 3 states:

As an exception, if the type of x is a defined pointer type and (*x).f is a valid selector expression denoting a field (but not a method), then x.f is shorthand for (*x).f.

The emphasis here is on "defined pointer type." In the code, *s is a composite pointer literal type, not a defined pointer type. Therefore, I believe this rule does not apply in this case.

Furthermore, in selector rule 1, it only states that "x.f denotes the field or method." The term "denotes" is somewhat ambiguous and does not imply implicit pointer indirection.

[Axel Wagner]

Hi,

However, I would like to point out that selector rule 3 states:

As an exception, if the type of x is a defined pointer type and (*x).f is a valid selector expression denoting a field (but not a method), then x.f is shorthand for (*x).f.

The emphasis here is on "defined pointer type." In the code, *s is a composite pointer literal type, not a defined pointer type. Therefore, I believe this rule does not apply in this case.

As I mentioned on slack, the fact that this is not a defined pointer type means that is not the right rule to look at. Instead, you need to look at the first rule in the list.

Furthermore, in selector rule 1, it only states that "x.f denotes the field or method." The term "denotes" is somewhat ambiguous and does not imply implicit pointer indirection.

I don't think this particular level of language-lawyering is useful. The spec is not a legal document or anything like that and should be read for intent.

Writing `f().i` is allowed and well-defined, so the goal should be to justify *that* it is correct, not to come up with readings making it incorrect. A gracious reading of the spec here seems pretty clear.

在2024年7月17日星期三 UTC+8 12:51:48<Ian Lance Taylor> 写道：

On Tue, Jul 16, 2024 at 9:29 PM 王旭东 <wxd...@gmail.com> wrote:
>
> Hi, I have a question about "addressable."
>
> The following code illustrates my question (see the comments):
> https://go.dev/play/p/xpiPXuEqh0O?v=gotip
>
>
>
> I also posted question in the Gopher Slack channel, and @Axel Wagner provided a detailed explanation, suggesting that this might be a gap in the Go specification.
> @Jason Phillips recommended that I ask this question in the GitHub issues and the golang-nuts mailing list.
>
> I really appreciate everyone’s help mentioned, but I still don’t have a clear conclusion.
>
> To simplify: my question is why the result of myfunReturnPointer() is addressable if we strictly follow the specification.


In https://go.dev/ref/spec#Selectors the spec explains that if the
type of x is a pointer, then the selector expression x.f is shorthand
for (*x).f. That is the case in your playground example: the
expression myfunReturnPointer().i is short for
(*myfunReturnPointer()).i. The pointer indirection
*myfunReturnPointer() is addressable according to
https://go.dev/ref/spec#Address_operators. So this is a field
selector of an addressable struct operand.

Ian

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0fb5aa3e-4568-4520-bd42-ff01c1a2bd54n%40googlegroups.com.

[王旭东]

Understood! I appreciate all your help.

@Axel Wagner
@Jason Phillips
@Ian Lance Taylor

Thanks again!
Xudong