Re: [boost] [Review] Fusion

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-16 06:40:03

Tobias Schwinger wrote:
> Douglas Gregor wrote:
>>    pair: I tripped over the name of this entity a bit. It's a little
>>    odd to have a "pair" with only one kind of data. I guess I'd feel
>>    better if this were called "keyed_value" or "key_value", because
>>    it's easier for me to copy with a typed key than it us for me to
>>    have a pair that's very different from std::pair.
> 
> I had a similar feeling about the "half runtime pair" when reading the
> documentation. After a deeper look and actually using the library, my
> scepticism vanished, however, because:
> 
> 1.
> 
> When writing Fusion algorithms there are in fact two control paths to 
> take care about: the template instantiations and the runtime behaviour. 
> I experienced that it makes sense to work out the compile time path 
> first, which is the point where the data structures are chosen. 
> In the compile time world, Fusion pairs are just pairs ;-).
> 
> Using "keyed_value" for e.g. the state with fusion::fold seems 
> misleading to me, while using a "pair" makes a lot of sense.
> 
> 2.
> 
> The only difference between the Fusion and STL pair concept is the 
> 'first' member variable. The current name reflects these conceptual
> similarities.

Yet another frame thought that I've come to consider recently is
to altogether discard the notion of "half runtime pair" and simply
gravitate towards std::pair or any structure that conforms to the
STL concept. For typical uses of fusion::map, for example, one can
simply use boost::compressed_pair which automatically optimizes
away the key or the data part (typically the key). The disadvantages
of this approach are:

1) boost::compressed_pair is needlessly more expensive (at compile
    time) than fusion::pair
2) The key type cannot be forward declared.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net