Re: [boost] [local_function] any interest in a LocalFunction library?

Subject: Re: [boost] [local_function] any interest in a LocalFunction library?
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-09-15 20:00:55

On 9/15/2010 10:56 AM, Lorenzo Caminiti wrote:
> On Sun, Aug 22, 2010 at 11:09 AM, Lorenzo Caminiti
> <lorcaminiti_at_[hidden]>  wrote:
>> Hello all,
>>
>> Is there interest in a library that implement local functions for C++?
>>
>>
>> Boost.LocalFunction (PROPOSAL DRAFT)
>
> Hello all,
>
> Based on our discussions so far (thanks a lot for all the input!) I am
> starting to make some actual design decisions. These decisions are not
> final and they are of course subject to continuous improvement and
> necessary changes that will be identified by Boosters during the
> formal review of the library. However, for the current development
> stage of the library I will make these decisions and move forward
> (otherwise I keep changing things forever).
>
> If you have a strong opinion on any of these topics, please voice your
> opinion _now_ so to minimize the amount of my re-work later :)
>
> CURRENT STATUS
>
> 1) I will name the library Boost.Local and this will include local
> functions (BOOST_LOCAL_FUNCTION/BOOST_LOCAL_FUNCTION_END/BOOST_LOCAL_FUNCTION_END_RENAME)
> as well as local constant blocks
> (BOOST_LOCAL_CONST/BOOST_LOCAL_CONST_END).

The name seems reasonable.

> 2) I will require users to use `this_` instead of `this` inside local
> functions when the enclosing object is bound. The local function is
> internally implement as a _static_ member of a local class so `this`
> will simply not be available and it cannot be used by mistake instead
> of `this_`.
>
> 3) I will use the `bind` preprocessor "keyword" for the parenthesized
> syntax as in `(bind)(...)` and `(const bind)(...)`. `bind` is more
> readable than `bound` or `closure` (plus I do not know English well
> enough to figure out if `bound` is more correct because it is used in
> declarative as supposed as imperative context... English native
> speakers: Help me!).
>
> 4) Local functions will use a trick that will allow them to be passed
> as template parameters (this is not possible for plain member
> functions of local classes). This will allow to pass local functions
> to algorithms like `std::for_each` which is a major use case of C++0x
> lambdas. (Still local functions will suffer the important limitations
> that they cannot be defined at expression level and they cannot have
> template parameters.)

This could be very convenient.  Be sure to address the performance 
issues when using such a construct (I am myself curious; it seems that 
John's done some preliminary work).

> 5) When used within a template, the macros `BOOST_LOCAL_FUNCTION_TPL`,
> `BOOST_LOCAL_CONST_TPL`, etc will need to be used (otherwise you get a
> compiler error). This is necessary for the library to apply `typename`
> from within the template where the type determination is context
> depend (and given that C++ does not allow to use `typename` outside
> templates). The same convention is used by Boost.ScopeExit, etc.

I'm sorry, but in what context are these macros necessary?

> 6) Local functions will support recursion.

How would that be effected?

> 7) Local functions will support optional default values for non-bound
> parameters (as usual for C++ functions).

Might as well.

> 8) I will not provide the `BOOST_LOCAL_BLOCK` but only the
> `BOOST_LOCAL_CONST`. The only reason for `BOOST_LOCAL_BLOCK` would be
> to break to its exit using `return` and a local function executed
> immediately after it is defined can be used for that purpose.

I think, if only for completeness and symmetry, something equivalent to 
BOOST_LOCAL_BLOCK should be provided.

> 9) I will not allow a local function to "inherit" from another local
> function. It seems there is no use case for such a feature (and I am
> not really sure how to define this behavior in the first place because
> inheritance makes sense between objects and not between functions...
> see related Boost email thread).
>
> 10) I will not merge Boost.Local with Boost.ScopeExit into a more
> generic Boost.Scope library. However, I will provide macros
> `BOOST_LOCAL_EXIT/BOOST_LOCAL_EXIT_END` which will work like
> Boost.ScopeExit plus they will allow to bind `this`. Boost.ScopeExit
> does not allow to bind `this` correct?

Perhaps the Boost.ScopeExit macros can simply be implemented in terms of 
BOOST_LOCAL_* macros...?  Seems silly to ultimately retain duplicate 
copies of the same implementation.

> OPEN ISSUES
>
> a) I am not sure if local functions can be nested into one another. In
> other words, I do not yet know if it will be possible to define a
> local function from within another local function.

What are the issues you're running into?

> b) I am not sure if I will provide unnamed local functions (void or
> not) and if so what their syntax will look like. It seems if you need
> this you can just use the local functions macros to program it without
> a dedicated syntax (but still discussing...).

I think this, like the BOOST_LOCAL_BLOCK macro, is mildly useful, 
trivial to implement given the already-proposed functionality, and 
benefits from having a standardized macro.  My feeling is to include 
this functionality.

> c) I am not sure if I will provide local functions that execute
> immediately after they are defined. This might relate to b). Again, if
> you need this you can simply call the local function right after you
> define it without a dedicated syntax (but still discussing...).

How is this different from (b), exactly?  I.e., it doesn't seem possible 
to create an unnamed local function and execute it sometime later...

> (I will eventually document all these points, and more, in the library
> documentation under the "Rational" section.)

Excellent.

- Jeff