Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Peter Dimov
I need to warn you that there is very little chance for your patch to be accepted in this form. Extending _bi::listN (I'd suggest making them conforming MPL or fusion sequences) needs to be done non-intrusively and in a separate header.
-----
I understand what you mean here but didn't you say that the whole thing would be easier if one was to use a fusion tuple as L? I assumed that would have been the acceptable solution since you suggested that yourself. I would expect that making bind switch to tuple would be less work and more beneficial than introducing another sequence type (which I think is a lot more testing). FWIW, I'd be less interested in adding a new sequence type.
I understand Peter. It can be done non-intrusively. Fusion(2) was designed with a requirement that you should be able to "adapt" any type of tuple or tuple-like (even plain structs) sequences. I did that with boost.tuple, for example. One reason is backward compatibility. Boost.tuple already has a tremendous user base. I do not want to cause disruption by replacing Boost.tuple with fusion's native sequences. That would case disruption in many ways. So would replacing boost.bind's tuples. Adaptation is the way to go. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net