On Fri, Jul 17, 2026 at 9:17 PM [email protected] <[email protected]> wrote: > > Hi, thanks for the explanations. > > I think the example in the doc: > > a := 1 > f := func() int { a++; return a } > x := []int{a, f()} // x may be [1, 2] or [2, 2]: evaluation order between a > and f() is not specified > > is exactly why I'm so confused. Maybe the evaluation order of function calls > and values should be specified under a single rule somehow? Before this > becomes a widely spread most-ask job interview question, perhaps?
We could fully define the evaluation order of all operations in Go. So far we have not done so. The main argument against it is runtime efficiency: if the evaluation order is fully defined, the compiler is more constrained, and there is less flexibility in generating optimal code. That said, there are other areas where Go has decided to specify the language in ways that tend to make code run less efficiently. There can be a tradeoff between making the code readable and making the code run fast. Go tends to prefer to making the code readable. With that in mind, it worth observing that code like the example above is not clear. The variable a is being read by the slice expression, and it is also being modified by the slice expression. That is confusing. This is not a case in which there is a trade off between readability and efficiency. It's a case in which the code is not readable. If I saw code like this in a code review, I would reject it. I've personally felt for a long time that Go should make it an error for a variable to be both read and written in a single expression. Unfortunately that is difficult to implement in the fully general case. 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXMEwUDMgv4TUathHHhmd6AJ--ndeJsfNGKhTkG1Ds0OQ%40mail.gmail.com.
