21–30 of 55 posts
Earlier quoted context omitted.
Collecting tasks from all iterations to await before returning.
Fair enough. But it's something like 5 lines of code to write that manually, and writing it explicitly is clearer. With implicit function-scoped defer, someone might refactor the code to inline the body of the function into its caller and break it.
I think most of the people who understand the basic principles of how computers (and many languages) work wouldn’t be surprised by any of the „gotcha” described in this article. It seems to be written for people who just started working with golang without any or little knowledge about information technology.
I am not sure about this. Swift for example also has `defer` statements but its behavior differs from Go's. Swift executes defer statements at the end of the block, not the end of the function. And AFAICR Swift doesn't evaluate the parameters right away like Go does. If you have already read how defer works in detail in Go, you probably already know this. Devs new to the language or those that haven't used defer in t…
#4 can also be fixed with: for i := 0; i
This is too sneaky and seems like poor form. I'm curious what good use-case there is for this, that the language bothered to support and allow this to even compile. Duplicate variable name declaration + referencing in the same scope is unintuitive at best, and just seems wrong .
for i := 0; i Also read the official blog post on defer: https://blog.golang.org/defer-panic-and-recover It covers about half of these gotchas by laying out how the defer statement works in plain English. The other half (like how closures work inside loops in Go) are covered elsewhere in the language tour. I do really like the visualizations! Makes it very clear how these mechanics work.
The content is good, and it is accurate, but even though defer can be a bit tricky this blog post series seems to literally be describing the entire semantics of "defer" as "gotchas". It's not that tricky!
Earlier quoted context omitted.
This is too sneaky and seems like poor form. I'm curious what good use-case there is for this, that the language bothered to support and allow this to even compile. Duplicate variable name declaration + referencing in the same scope is unintuitive at best, and just seems wrong .
I don't feel that it's in more poor form than the solution suggested in the article: for i := 0; i This shadows `i` pretty much the same amount as what I wrote. If `i` gets a different name inside the lambda, then it'd also be worse because then you could accidentally use `i` still.
Also read the official blog post on defer: https://blog.golang.org/defer-panic-and-recover It covers about half of these gotchas by laying out how the defer statement works in plain English. The other half (like how closures work inside loops in Go) are covered elsewhere in the language tour. I do really like the visualizations! Makes it very clear how these mechanics work.
Btw, the first part was more advanced (but again for beginners and intermediate gophers) -> https://blog.learngoprogramming.com/gotchas-of-defer-in-go-1...
It's indefensible that defer works on the function and not on the scope.
func f() {
x := ...
if x.something() {
x.doSomethingEarlier()
defer x.cleanup()
}
// use x however you like
}
func f() {
x := ...
if x.something() {
x.doSomethingEarlier()
defer x.cleanup()
// use x however you like
} else {
// use x however you like
}
}
On the flip-side is of course that this doesn't work like most would probably want in function-scoped:
for i := 0; i for i := 0; i I think most of the people who understand the basic principles of how computers (and many languages) work wouldn’t be surprised by any of the „gotcha” described in this article. It seems to be written for people who just started working with golang without any or little knowledge about information technology.
Defers just feel like a watered down version of what you get with good scoping and RAII. They're a half measure for something programming languages solved decades ago.