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 ?