Earlier quoted context omitted.
Crikey! You wouldn't wanna allocate closures in a loop anyway, would you? Even if the compiler is smart about it. Doesn't read so well either.. what's wrong with adding a simple argument to your anonymous-func allocated outside of a loop? It's readable, and there are no 'gotchas'. The args are evaluated at the point of defer/go, not func execution. Simples. Shadowing bites you sooner or later if it becomes a habit an…
> Crikey! You wouldn't wanna allocate closures in a loop anyway, would you? Very often yes I do. Go encourages synchronous APIs, making it up to the caller to add concurrency. This is great, in my opinion. E.g. this is a common pattern: var wg sync.WaitGroup ch := make(chan int, len(items)) for _, item := range items { item := item wg.Add(1) go func() { defer wg.Done() ch Similar patterns with defer, although yes I'd…
But well, guess it comes down to subjective stylistic preferences here =)
> So that even if "do something" throws exception… err… panics… the file gets closed.
Your defer as placed in your above example is already scheduled to run always, even on a later panic. (After all, how else could one `recover` from a `panic` if it wasn't for `defer`?) I don't see the point of the double-closing at all here..