[boost] Re: tuple patch (constructing from a pair)

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-15 10:25:06

Joel de Guzman <joel_at_[hidden]> writes:

> Larry Evans wrote:
>> On 02/15/2005 08:08 AM, Larry Evans wrote:
>> [snip]
>> 
>>>> Yes, it is a non-member function. No, it does not mutate s.
>>>> It does return another set. It is purely functional (no side-
>>>> effects).
>> Then it's different from tuple<T1,...,Tn> since any mutating
>> operation Ti::op on an instance of Ti can be performed on the
>> corresponding member variable in an instance of tuple<T1,...,Tn>?
>
> I don't understand what you are saying.
>
>> See boost-sandbox.sourceforge.net/vault/cppljevans/field_visitor_tests
>> /field_sets.hpp for an example of what I had thought you were
>> talking about here:
>>  > fusion::vector, fusion::list, fusion::set and fusion::map
>>  > all have data. These are different incarnations of the
>>  > tuple with different characteristics.
>> when you said fusion::set had data.  Having data implies, at least
>> to me, that the data can be modified.
>
> I do not understand why we are having an impedance mismatch here.
> It seems to me that we're in different universes. I do not even
> understand why this matters at all. Having data *does not* imply
> that the data is mutable. It can be const, for example. Or, in
> purely functional terms, you do not wish to have side-effects.
> Still, the data is there, in real bits and bytes.

And in fact it can be mutated, at least in most fusion structures.
It's the _structure_ that can't be mutated.  Just like boost::tuple.
You can change the elements, but you can't change their number and
type (in-place).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com