I don’t disagree at all. And I feel the same way - there’s no reason to write code like that and it certainly shouldn’t pass review. I think allowing efficiency for the compiler is orthogonal. Fully specify the language so that it can be efficient and disallow the constructs that would hinder that. UB is like a “your mileage may vary” claim - it’s not very useful and hinders agreement.
> On Jul 18, 2026, at 5:53 PM, Ian Lance Taylor <[email protected]> wrote: > > 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. -- 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/F7D38311-91E6-4CB2-AB7B-505869BBA3D4%40me.com.
