From: Joel de Guzman (joel_at_[hidden])
Date: 2005-02-15 20:31:28
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.
>>>Also, I think having both 5) and 6) will be confusing. I'd prefer to
>>>get rid of 6). This will obviously break some code, but it will be
>>>much easier to adapt old code to the new interface than it was,
>>>e.g., to adapt code to use the new iterator adaptors.
>>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."
> Still, I'm not sure why you can't eliminate 6) at the same time you introduce
> fusion. People who need extensible tuples can use fusion sequences.
That will lessen my work a lot. But don't you think that's too
abrupt? Perhaps those who use old tuple's advanced features are
advanced users anyway who won't mind tweaking their code? Toughts?
-- 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