On Thu, Jun 1, 2017 at 6:40 PM, Will Hawkins <hawki...@borlaugic.com> wrote:
> Hello awesome community!
>
> I am so honored to be a part of the great community of gophers around the
> world. Thank you to everyone who makes it so inviting to everyone who wants
> to participate.
Thanks for the nice intro.
> I am writing today to ask about some puzzling behavior with respect to
> dereferencing pointers, function evaluation and tuple assignment. I have the
> following code snippet:
>
> type T struct {
> i int
> }
>
> func (t *T) sideEffectPtr() *int {
> t.i += 4
> return &t.i
> }
>
> func derefIntPtr(i *int) int {
> return *i
> }
>
> func main() {
> var d = T{i: 200}
> var e = T{i: 200}
> a, b := derefIntPtr(d.sideEffectPtr()), derefIntPtr(d.sideEffectPtr())
> aa, bb := *e.sideEffectPtr(), *e.sideEffectPtr()
> fmt.Println(a, b)
> fmt.Println(aa, bb)
> }
>
> You can see the code in action on the playground here:
> https://play.golang.org/p/wGsvYWXEqf
>
> The output is surprising, to say the least:
> 204 208
> 208 208
>
>
> From what I understand, the right hand side of a tuple assignment is
> completely evaluated before the assignment happens.
That is true, but I don't think it's relevant here. That tells us
that the two instances of `*e.sideEffectPtr()` are evaluated before
either value is assigned to aa or bb. But it doesn't tell us anything
about the exact sequence of steps used to evaluate those two
instances.
> I also think that I
> understand that for evaluations not covered specifically by the language
> specification, the particular order of the evaluation is not defined. In
> other words, in
>
> aa, bb := *e.sideEffectPtr(), *e.sideEffectPtr()
>
> the calls to sideEffectPtr() may happen in any order.
That turns out not to be the case. The "Order of Evaluations" section
of the spec says that in an assignment statement all function calls
are evaluated in lexical left-to-right order.
> However, I would imagine that, no matter what the order, the dereference
> operation would happen immediately after the first function call and before
> the second. That would lead me to believe that one output would be 204 and
> the other would be 208.
Unlike function calls, the language spec doesn't anything about when a
dereference operation is executed. And as you can see the current
compiler does not do the dereference immediately after the function
call.
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
