On Monday, 29 August 2016 13:36:00 UTC-4, Conrad Irwin wrote:
>
> because of the automatic escape detection, I no longer think of a pointer
> as being the intrinsic address of a value; rather in my mind the & operator
> creates a new pointer value that when dereferenced returns the value.
>
> With that mental model mixup in place, it's obvious why "&f()" makes sense
> — it's just creating a new pointer to the value returned by "f()".
>
>
If you instead keep in mind that the meaning of "&" is supposed to be
> closer to "what's the address of this thing?" for the purpose of
> identity-based equality and reference sharing, it makes more sense to
> prohibit "&m[k]" or "&f()" because each time you run those you may/will get
> a new pointer (which is not useful for identity-based equality or reference
> sharing). It still would be useful for my case which was essentially
> converting one type to an "optional" type, but maybe that's enough of an
> edge case that it doesn't matter.
>
The composite literal syntax &T{...} may have led you astray, as it is not
equivalent to "&" + "T{}". That is, it doesn't mean "here's an expression
of type T, give me its address", it means, "create a new variable of type
T, initialize it, then give me its address". It's shorthand for:
p := new(T); *p = T{...}; p
The key thing is that only variables have addresses. (Escape analysis is
irrelevant: all of this applies equally to stack and heap variables.)
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
