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...
>>> (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!
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk