[boost] Re: Fusion plan [was Re: tuple patch (constructing from apair)]

From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-04-29 06:59:07

On 02/15/2005 02:53 PM, Jonathan Turkanis wrote:
> Joel de Guzman wrote:
> 
>>Jonathan Turkanis wrote:
>>
>>>Joel de Guzman wrote:
> 
> 
>>>>5) Provide a tuple TR1 interface on top of fusion.
>>>>6) Provide a backward compatible interface (for old tuples) on
>>>>   top of fusion.
[snip]
>>5 and 6 will have to either-or through a PP define. Yes, it
>>can't be both at the same time. We can deprecate 6 and
>>phase it out in the future. We can't simply kill it now.
>>TR1 deos not provide a way to extend a tuple, for example.
> 
> 
> Okay, I thought people who used cons lists were relying on an implementation
> detail, but I see that it is  documented under "advanced features."

Since the ForwardOp, as defined here:

http://www.boost.org/libs/mpl/doc/refmanual/fold.html

is pretty equivalent to a cons operation when it's defined as:

template<class Head,class Tail>
struct forward_op_cons
: Tail
{
     Head value;
};

couldn't fusion's fold be modified to allow the
result to be a cons-like tuple.  Then, if needed,
a simple "adapting" derivation can make the
result look pretty much like the existing tuple.

IOW, couldn't fusion's tuple result be a sequence,
as done by fold_seq in the fold_seq_test.zip file
here:

http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=cppljevans/mpl

?