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

Subject: Re: [boost] [local_function] any interest in a LocalFunction library?
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-09-15 10:56:53

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).

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.)

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.

6) Local functions will support recursion.

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

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.

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?

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.

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...).

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...).

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

--
Lorenzo