пт, 5 июл. 2019 г. в 18:39, Nevin Flanagan <alestane@playsmith.net>:
>
> It seems like what is really wanted is a way to clean up a scope when it closes, so it seems like we should just do that. Create a new block frame, such as "defer ... end" or "exiting ... end". Everything that is in scope at the point where the block begins is in scope throughout the block. However, the contents of the block are not executed inline; rather, once execution reaches the point in the code where the block begins, a deferred-execution guarantee is made for the contained code, which will be executed when the scope immediately containing the exiting ... end block is exited (in newest-guarantee-first order).
Why we try to find new way to do this if it could done with existing syntax.
https://raw.githubusercontent.com/kov-serg/lua-aux/master/scope.lua
More over we could control implementation details with several lines of code.
I'm really not a big fan of that. Not only does that have a ton more overhead thanks to needing to construct extra closures, but it messes with control flow -- you can't, for example, optionally return from the code. You have to have the caller inspect the return value and decide whether it needs to return or if it should keep going. At that point, it's barely even syntactic sugar; if you're ALREADY writing a worker function and passing it to another function ("scope" instead of "pcall" but still...) and you have to inspect the return values either way, what have you really gained?
The advantage of having the syntactical support built into the language itself instead of provided via metaprogramming is that it means you can take advantage of all of the other features of the language. I wholly believe that <toclose> serves a purpose that CANNOT be elegantly and efficiently replicated without it. And that's exactly what you should be looking for when adding something to a language.
I mean, yeah, I don't think angle brackets are an ideal syntax for it, and "toclose" is something of an awkward name, but everything else about it I think is sound. The only alternative that's come up in all of this bikeshedding that's equivalently expressive is support for a "finally" block, which has its comparative pros and cons. (Weighing the alternatives, I like finally SLIGHTLY better because it gives better control over error handling, but it has bigger syntactical problems and requires more boilerplate for common use cases.)
/s/ Adam
