Re: [boost] [review] Fusion review, finalization

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-15 16:47:30

Tobias Schwinger wrote:
> Joel de Guzman wrote:
>> Tobias Schwinger wrote:
>>>   If so (even occasionanlly), it would be necessary to have at least accessors 
>>>   for pair members (they are needed to keep the evaluation lazy, see line 211) 
>>>   or, ideally, if there would be a normalization between the STL and the MPL 
>>>   pair concepts (then MPL's accessors, 'first' and 'second', could be borrowed).
>>
>> If my suggestion to make mpl/fusion pair fully conforming mpl/fusion
>> sequences is accepted, then you can use code like mpl::begin<_> or
>> mpl::at<_, N>.
>>
> It's a very cool suggestion, IMO (just for the protocol: seems 'mpl::begin' was 
> supposed to read 'mpl::front').
> 
> But it seems we're still talking about different pairs of shoes (shoes of pairs?):
> 
> Given the (actually) unspecified type members of 'mpl::pair' get "_type"-suffixes, any pair would just work with MPL *as a pair*. That is, the 'first' and 'second' metafunctions are trivial and (unlike all sequence-stuff) not tag-dispatched, so their instantiation is very lightweight and especially nice for within iteration...

Understood.

>>>   (It would also be cool if one could just typedef the lambda expression to nested 
>>>   result or inherit from a wrapper. I don't know whether it's possible and a good 
>>>   idea - this part is just loud thinking)...
>>
>> Hmmm... can you elaborate. I lost you here.
>>
> 
> OK. I believe it works best with some imaginary code:
> 
[snip cool code]

Interesting! at the very least :) More ideas to meditate on!

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net