[Boost-users] Re: Re: [MPL] map question

Daniel Wallin writes:

Aleksey Gurtovoy wrote:

...

David Abrahams writes:

...

Hum. Seems a bit counterintuitive that protect doesn't apply equally well to this case.

??? As I tried to explain in my previous reply, 'protect' already has a well-defined semantics in lambda expressions, and it's quite different from what is needed to support "nested scopes". It would be nice to have a single magic primitive that would work the way you want it to work depending on the particular use case at hand, but I for one have no knowledge of how to implement one.

I'm sorry if I'm being thick here, but I can't grasp this. To me protect looks exactly like what is needed here. I have always thought of protect as delaying the placeholder substitution one step,

Well, again, it's not what it does. If we are to talk about introducing another primitive that would cover the OP use case, then it's another discussion (which should be taken to the developers list).

so that:

typedef fold< map_types , map_types , copy< get_types<_2> , inserter<_1, protect > > >

...

::type result;

Would work. Changing the protect specialization in

boost/mpl/preprocessed/gcc/full_lambda.hpp

to this:

template< typename T, typename Tag > struct lambda< mpl::protect<T>,Tag, int_<1> > { typedef false_ is_le; typedef T result_; typedef result_ type; };

Makes protect work like I thought it did, and makes the above compile.

And breaks the code relying on the current semantics.

I don't really understand the workings of lambda, so this probably breaks something else.

Yes, it does.

So what am I missing? Why can't it work like this?

Because it's unspecified how many times a lambda expression is passed through the 'lambda' metafunction before the actual invocation takes place. -- Aleksey Gurtovoy MetaCommunications Engineering