Re: (not) handling new programming idioms with grace

[Patrick Donnelly <batrick@...>]

On Wed, Jul 18, 2018 at 9:19 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> If Roberto wants to go with a scope-qualified local, at least it's a
>> slippery slope to laying a new control structure on top of it :)
>> Though it will be important that exit is called on the locals in the
>> reverse order of declaration.
>
> We are quite familiar with these "slippery slopes". It is in fact a
> hard argument to not add scope-qualified local. We usually add a
> feature to solve a problem, not to create new ones.
>
> We had something (scope-qualified locals) that seemed to be enough.
> Now we have this list of problems:
>
> - It does not create a new scope by itself;
> - It is not visible enough;

These two are related. I think people are trying to apply Python's
solution to this as a model for "something that has worked". I want to
point out the reasons why Python requires a control structure but Lua
would not: Python's locals are function-scoped. Declaring a local in
Python means it doesn't go out of scope until the function returns.
For this reason, Python requires an explicit control structure to
define the lifetime of the variable. Lua does not have this
limitation.

The extra "scope" makes the variable lifetime unnecessarily verbose.
This is not something Lua should adopt. Do we require every local to
have explicit scope:

do
  local foo = 0
  do
    local bar = 1
    ...
  end
end

? No.

> - It still does not solve the problem for global variables;

There are more appropriate idioms for this that were adopted by .e.g
C++. In the case of a mutex:

static std::mutex m;

int Foo::bar() {
   std::lock_guard<std::mutex> lock(m);
   ...
}

i.e. you can define the scope by creating a new wrapper object in a
scoped local.

-- 
Patrick Donnelly