On Fri, Jun 2, 2017 at 12:41 AM, Ian Lance Taylor <i...@golang.org> wrote:
> 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.
Thank you for your quick and very helpful reply, Mr. Taylor. It turns
out I read a previous message of yours a few days ago on an unrelated
list (about poison malloc in gcc) so it's quite the coincidence!
>
>
>> 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.
Thank you for that clarification.
>
>
>> 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.
>
You are, obviously, absolutely correct. I am embarrassed to say that I
mistranslated my understanding of the spec into my message. Thank you
for making the correction.
>
>> 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.
This is the bit of information that I was hoping you'd have. It seems
like an odd omission from the spec. On one hand, it clearly allows the
compiler to perform optimizations that otherwise might not be
possible. On the other, though, it would seem to introduce the
possibility of data races or, as in the case here, unexpected results.
Just my naive opinion. If you had thoughts about it, I'd love to hear
your expert opinion.
I sincerely hope that what I asked was not a stupid question. It gave
me lots of trouble and I worked through the problem with several
others and we could not figure out the cause of the discrepancy.
Thanks again for your response!
Will
>
> 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.
