Comment by gf000
Making it lexical scope would make both of these solvable, and would be clear for anyone reading it.
You can just introduce a new scope wherever you want with {} in sane languages, to control the required behavior as you wish.
Making it lexical scope would make both of these solvable, and would be clear for anyone reading it.
You can just introduce a new scope wherever you want with {} in sane languages, to control the required behavior as you wish.
What's an example of where you'd need to do that?
I can't recall ever needing that (but that might just be because I'm used to lexical scoping for defer-type constructs / RAII).
Someone already replied, but in general when you conditionally acquire a resource, but continue on failing. E.g., if you manage to acquire it, defer the Close() call, otherwise try to get another resource.
Another example I found in my code is a conditional lock. The code runs through a list of objects it might have to update (note: it is only called in one thread). As an optimization, it doesn't acquire a lock on the list until it finds an object that has to be changed. That allows other threads to use/lock that list in the meantime instead of waiting until the list scan has finished.
I now realize I could have used an RWLock...
I frequently use that pattern. For example, something like this:
a := Start()
if thingEnabled {
thing := connectToThing()
defer thing.Close()
a.SetThing(thing)
}
a.Run(ctx)
You can start a new scope with `{}` in go. If I have a bunch of temp vars I'll declare the final result outside the braces and then do the work inside. But lately days I'll just write a function. It's clearer and easier to test.