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-14 22:40:53

On Tue, Sep 14, 2010 at 2:25 PM, John Bytheway
<jbytheway+boost_at_[hidden]> wrote:
> On 14/09/10 03:52, Lorenzo Caminiti wrote:
>> I agree, if the macro is named `..._FUNCTION` then `return` is not
>> confusing. What is the use case for unnamed local functions? Is it
>> just the breakable feature?
> <snip>
>> All in all, you can always just define a named local function and call
>> if right away with one extra line of code:
>>
>> BOOST_LOCAL_FUNCTION(
>> (void) (unamed)( (bound)((this)(&x)) )
>> ) {
>>     if (x <= 0) return;
>>     this_->x_ = x;
>> } BOOST_LOCAL_FUNCTION_END(unamed)
>> unamed();
>>
>> I am not sure of the utility of unnamed local functions but if there
>> is a clear use case for them, they would be really trivial to
>> implement. I think what we need to find is a good use case for this.
>
> One thing that occurs to me is the possibly utility of unnamed local
> functions which are not void.  For example, I sometimes want to have a
> variable which has to be non-const for a bit while I initialize it, but
> is then const (in principle).  It would be nice to allow enforcing this
> (somewhat the reverse of BOOST_BLOCK_CONST).
>
> So, code like this:
>
> Foo y;
> y.setMagic(x);
> // y should not be changed hereafter
>
> which can be implemented using the stuff you've already offered as for
> example
>
> BOOST_LOCAL_FUNCTION(
> (Foo) (unamed)( (bound)((&x)) )
> ) {
>  Foo y;
>  y.setMagic(x);
>  return y;
> } BOOST_LOCAL_FUNCTION_END(unamed)
> Foo const y = unamed();
>
> but is there value in providing dedicated functionality?  e.g. there are
> three occurrences of 'Foo' there which might in theory by named only once.

If you could pick, what would be your preferred syntax in this case?

>
> Another closely related issue is when you want to have an object briefly
> to pass to the constructor of another but destroy it soon afterwards
> (i.e. not have the order of construction be the reverse order of
> destruction); local functions could help there too.  Right now I might do
>
> boost::scoped_ptr<Bar const> w(new Bar(x));
> Foo y(*w);
> w.reset(); // Dispose of w soon, e.g. to free resources
> // Proceed to use y and never mention w again
>
> whereas with local functions I could do
>
> BOOST_LOCAL_FUNCTION(
> (Foo) (unamed)( (bound)((&x)) )
> ) {
>  Bar const w(x);
>  return Foo(w);
> } BOOST_LOCAL_FUNCTION_END(unamed)
> Foo y = unamed();
>
> and again it might be helpful to support this use case directly.

Again, if you could pick, what would be your preferred syntax in this case?

>
> I'm not convinced either of these (alone or together) is indeed worth a
> dedicated syntax, but they're other use cases to consider.  In
> particular, these are cases where the name of the function doesn't
> really matter (and would be troublesome to settle on -- I'd probably use
> "make_y" or something similarly banal).

Thanks for the examples. I am not sure I can provide a dedicated
syntax due to the presence of `type var-name = ...` _after_ the local
function declaration macros but if you (as well as other Boosters)
propose an ideal macro syntax, I can see if I can implement something
like that.

--
Lorenzo