51–60 of 146 posts
I don't know all that much about compilers, but I'm slightly surprised that Go doesn't automatically optimize the first into being the same as the second.
I'm not the most proficient Go developer, but aren't the two examples doing two different things? In the first way, each branch allocates its own objectInfo struct. In the second way, all the branch exits share the same single objectInfo struct which I assume is implicitly initialized to the zero value by the compiler. Functionally these are the same, but couldn't you achieve the same results without named return val…
Earlier quoted context omitted.
defer can refer to and change the return values. This is useful, for example, when the deferred code can trigger an error that one wants to return, https://play.golang.org/p/MBmy9OocAG
Is that actually returning err as the deferred return value of test? In other words, to the caller of test it appears test returns the result of the deferred?
Earlier quoted context omitted.
As one would expect. The deferred code runs after the normal code in the function has ended, and before the calling code has resumed. Named return values are in scope and can be read and modified. Try it and see: https://play.golang.org/p/1ozFWDj15a
Cool. Can anything execute between the end of the deferer and the start of the deferred?
If you mean in the same context then, no.
What am I missing?
Earlier quoted context omitted.
I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.
It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 ( https://…
See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...
I don't know all that much about compilers, but I'm slightly surprised that Go doesn't automatically optimize the first into being the same as the second.
Generally, any modern optimization pipeline that includes global value numbering and basic memory dependence analysis will perform that transformation, yes.
Earlier quoted context omitted.
Ok now I got they are in scope. About defer, could you think of it like defer makes a function into a function with multiple entry and exit points, possible to be stopped and resumed, like a coroutine?
Ehm, not sure I understood, but I'd say no. Defer is just code that is executed in reverse order upon return from a fuction. It has nothing to do with coroutines. It's a cleaner way to write the usual C syntax of "goto cleanup_x" code. Go coroutines (goroutines) are functions invoked with the "go" keyword. These cannot be stopped or resumed, but might be (possibly) executed on a different thread. In any case, they ar…
I'd say more like the equivalent of a "finally" clause (or more) for your whole function.
Though not sure about the "executed in reverse order part" -- what's "in reverse order" about Defer? Except if you mean that multiple defers get executed "last seen first"...
I'm not the most proficient Go developer, but aren't the two examples doing two different things? In the first way, each branch allocates its own objectInfo struct. In the second way, all the branch exits share the same single objectInfo struct which I assume is implicitly initialized to the zero value by the compiler. Functionally these are the same, but couldn't you achieve the same results without named return val…
Yes, you can, but just naming the return variable takes care of this.
I'm not familiar with Go and I'm confused by the fact that even though the returned variable is named, e.g. "ch", that name is never mentioned in the function body. What am I missing?
If they are never mentioned in the body you probably have a return of the default nil value for the named return variables.
But then at least one return is not naked and returns some value, discarding the named one.
I think it's a bad use of named returns.