On 9/15/2010 10:56 AM, Lorenzo Caminiti wrote:
On Sun, Aug 22, 2010 at 11:09 AM, Lorenzo Caminiti <lorcaminiti@gmail.com> 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