Boost logo

Boost :

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.
>>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:

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 file


Boost list run by bdawes at, gregod at, cpdaniel at, john at