Comment by gf000

1 day ago

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.

7 comments

gf000

lowmagnet 1 day ago

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.

tgv 1 day ago

Currently, you can write

    if (some condition) { defer x() }

When it's lexically scoped, you'd need to add some variable. Not that that happens a lot, but a lexically scoped defer isnt needed often either.

iainmerrick 1 day ago
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).
- tgv 14 hours ago
  
  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...
raluk 12 hours ago
Having lexicial scope it is same as -> defer fn{if(some condition) x() }() within scope.
- tgv 8 hours ago
  
  Except 'some condition' may change, can be long, or expensive, so you likely need an extra variable.

atombender 1 day ago

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)