Re: error with d28016d16e9a (change to jsonencode.cc)

"John W. Eaton" <[email protected]> Thu, 1 Oct 2020 15:42:39 -0400
Newsgroups gmane.comp.gnu.octave.maintainers
Message-ID <[email protected]>
On 10/1/20 2:33 PM, Rik wrote:

> "should work", but needs to be checked.  The first lambda expression I 
> wrote for Octave would not work with capture which is why I used the 
> parameter-passing approach.

Do you remember what it was that didn't work?

Except for "this", lambdas capture by value by default.  Capturing 
"this" allows access to the current object, so instead of writing

   unwind_action restore_scope
     ([] (auto self) { self->pop (); }, this);

we can write

   unwind_action restore_scope ([this] (void) { pop (); });

and instead of

   unwind_action executing_callbacks_cleanup
     ([] (auto old_callback_props, auto &self)
      { old_callback_props->erase (self); }, &executing_callbacks, this);

we can write

   unwind_action executing_callbacks_cleanup
     ([this] () { executing_callbacks.erase (this); });

In this last case, "executing_callbacks" is also a file-scope static 
variable, so the lambda can access it directly without capture.

We could also decide to always use "[=]" when we need to capture 
something.  Then all variables that are needed, including "this" will be 
captured using the default rules for capture by value.

The unwind_action + lambda expression feature is definitely complicated 
and has a lot of options for how to use it.  There's no one right way. 
I'd just like to agree on a set of guidelines to make it as simple as 
possible to write, understand, and maintain.  My first pass at that would be

   * when possible, capture variables by value directly in the lambda 
expression instead of the unwind_action object

   * use lambda expression arguments and capture values in the 
unwind_action object only when necessary (for example, when the value is 
not a variable in the local scope)

and possibly

   * use "[=]" to capture local variables and avoid the redundancy of 
explicitly writing the list of captured variables since they will 
already appear in the lambda expression anyway

and, once we can move to C++14, maybe also add

   * use "auto" for lambda expression argument declarations

jwe