Thanks Axel, Ian! I am not actually questioning the current design, as you both said it is not a good practice to call a return statement as I wrote above, I am trying to understand the relation between memory, interface and order of evaluation. It is clear that the compiler takes account of whether a return statement is an interface or a struct and the memory size of the returned value, If I return a struct rather than an interface, it changes the order, If I add fields to the structs it changes the order. Is there a paper that I can find why the compiler considers them for ordering, why it is important for performance or anything else?
On Monday, September 21, 2020 at 8:06:31 PM UTC+3 Ian Lance Taylor wrote: > On Mon, Sep 21, 2020 at 9:34 AM 'Axel Wagner' via golang-nuts > <golan...@googlegroups.com> wrote: > > > > The evaluation order is defined here: > > https://golang.org/ref/spec#Order_of_evaluation > > The important part is that the order of evaluation in a return statement > is only defined for function calls, method calls and communication > statements, but not in relation to other operations. So, in > > return intNumber, setInteger(&intNumber) > > It is not defined whether `intNumber` or `setInteger(&intNumber)` is > evaluated first, as the former is none of those. I can't really tell you > why, but it has been discussed a couple of times, you might find something > using the search function on golang-nuts. > > > > If you want reliable behavior, you should assign the result first > > var intNumber Integer > > err := setInteger(&intNumber) > > return intNumber, err > > This flexibility is in the language to permit better code > optimization. The compiler can choose how to order memory loads and > function calls. It is not required to do a memory load, save it > somewhere, and then do the function call. > > Of course, this does have the downside that different compilers will > produce different behavior for the same code. So far we've decided > that that is OK. > > My personal attitude is if a single statement writes to a variable > other than by assigning to it directly, and the statement also reads > from that same variable, then the program is already confusing. While > we could lock down a specific order of evaluation, that won't help the > fact that the program is hard to read and hard to understand. So I > don't see a good argument for forcing many well written programs to > run very slightly slower in order to make poorly written programs > behave consistently. But I understand that other people feel > differently. > > Ian > > > > > On Mon, Sep 21, 2020 at 6:09 PM cs.ali...@gmail.com <cs.ali...@gmail.com> > wrote: > >> > >> Why does the compiler change evaluation order of return when adding a > new field to a struct? I didn't check the compiler output, I only guess it > somehow changes the order. > >> play > >> package main > >> import ( > >> "fmt" > >> ) > >> type Number interface { > >> Value() int > >> } > >> type Integer struct { > >> value int > >> additional int // remove this for different result > >> } > >> func (integer Integer) Value() int { > >> return integer.value > >> } > >> func main() { > >> number, _ := getNumber() > >> fmt.Printf("number val: %d\n", number.Value()) > >> } > >> func getNumber() (Number, error) { > >> var intNumber Integer > >> return intNumber, setInteger(&intNumber) > >> } > >> func setInteger(num *Integer) error { > >> num.value = 2 > >> return nil > >> } > >> > >> -- > >> 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...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/b7077f03-b0f4-454a-a587-ab9757164409n%40googlegroups.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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHsSFfjPzoOTVz7Q4fE%3DziCXhA5mbUWzSkQ5DADMyzWFw%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/2a0dab1c-9835-4d26-ab46-75731a23bcd9n%40googlegroups.com.
