This is a shallow, visual symmetry.
Per Go spec, Foo{} and 5 are not related in a meaningful way.
Foo{} denotes a runtime operation that creates a new instance of Foo
struct, and & takes an address of this instance.
5 is an integer literal https://golang.org/ref/spec#Integer_literals. While
it might not be spelled out explicitly, 5 is not something that exists at
runtime so you can't take its address.
5 only exists in the compiler. You can assign it to a variable (something
that exists at runtime) and take the address of that variable.
And when you think about it a bit, it can't work any other way which is why
it works that way in any language I can think of.
In fact, your idea of introducing a hidden, inaccessible, temporary
variable to hold the value of 5 just so that you can say &5 would mean
introducing a special case for & operator.
Implicit magic is rarely a good thing and in this case it doesn't give you
anything that you couldn't do trivially with explicit variable.
-- kjk
On Tuesday, February 27, 2018 at 1:14:01 PM UTC-8, Juliusz Chroboczek wrote:
>
> > You can't take the address of the return value of a function or a
> > conversion (which is conceptually just a function) because it doesn't
> > have a location in memory and thus doesn't have an address.
>
> I've never understood the reason for this limitation. I'd expect the
> compiler to box any value that I take the address of, i.e. automatically
> convert
>
> p := &f()
>
> into
>
> x := f()
> p := &x
>
> Another way to put it is that I don't understand the disymmetry between
>
> p := &Foo{}
>
> which works, and
>
> p := &5
>
> which doesn't.
>
> -- Juliusz
>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
