I could not agree more with Axel's assessment, and wanted to emphisize it for any Go-noobs reading this. An important part of the go philosophy is to write code that is as clear and simple as possible. It is not about compact code, or 'clever' code. Code should be easy to understand, even when skimming. A return statement that returns a value, and modifies it in the same statement, would not pass code review for me.
Just because you can, does not mean you should. On Wednesday, January 15, 2020 at 2:34:05 PM UTC-5, Axel Wagner wrote: > > And, just as an addendum: IMO, if the result depends on the order of > operations in a statement, prefer to rewrite it. Like, even if you are > satisfied with the behavior you are seeing *and* you can rely on it - it > should be clear by now that anyone looking at it will have to expand new > effort understanding it (and, you know, there might still be bugs in the > future). Rewriting the function call into its own statement gets rid of the > ambiguity and makes clear what's happening either way. > > On Wed, Jan 15, 2020 at 8:25 PM Paul Jolly <pa...@myitcv.io <javascript:>> > wrote: > >> > "when evaluating the operands of an expression, assignment, or return >> statement, all function calls, method calls, and communication operations >> are evaluated in lexical left-to-right order." >> >> My understanding goes as follows: the operands of the return statement >> are i and modify(&i). The comma after "return statement" in the above >> sentence is then important: because the only "function calls, method >> calls, and communication operations" in that list of operands are (is) >> modify(&i). >> >> Hence when i (as in the first operand) is evaluated is not specified. >> And therefore it's dangerous to rely on it being one value or another >> (which it could be given the example you provide). >> >> There was even some discussion at the London Gophers November 2019 >> meetup (where the conundrum was very related >> >> https://docs.google.com/presentation/d/e/2PACX-1vQ07uP_ldnSYzpaNb5AlZZ-_tL2mZuoNfQgxvsTKSM4aglYR-nuvyrZ8nK__r3YQTo1vqH-Hmax3aXs/pub?slide=id.g6239d05d0e_0_1 >> ) >> about whether it would be possible to statically flag potential errors >> like this. >> >> -- >> 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 golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CACoUkn7KA0Z-TDypdvM%3Du%3DyVPHuHFmtD%3DiTV2c98Vm%3Dqn4NcPw%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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/22823a87-11e9-413e-bbb0-abf6aa3b50d2%40googlegroups.com.
