Re: [boost] [review] Fusion review

From: dan marsden (danmarsden_at_[hidden])
Date: 2006-05-05 13:57:08

Joel de Guzman wrote:
>David Abrahams wrote:
>> Joel de Guzman <joel_at_[hidden]> writes:
>>
>>>> In the extension example, I see repeatedly the same patter
>>>> transferring the cv-ref qualification from one type to another.  Can't
>>>> that be made simpler for extenders?
>>>>
>>>>  typedef typename mpl::if_<
>>>>             is_const<Sequence>,
>>>>             std::string const&,
>>>>             std::string&>::type type;
>>> Can you point me to an example in the library, please?
>>
>> This isn't from the library code.  I copied it directly from the docs
>> at libs/fusion/doc/html/fusion/extension.html
>
>Ah, ok. I'll let Dan reply then. He wrote that part of the docs.

There is a common theme here when you need to return refs into the
container (from deref, at, at_key etc.) you need to const qualify the
result if the container is const. There is similiar logic in the library
proper, for example in the vector deref_impl we have:

                typedef typename
                    mpl::eval_if<
                        is_const<vector>
                      , fusion::detail::cref_result<element>
                      , fusion::detail::ref_result<element>
                    >::type
                type;

The ref/cref generation is currently in detail, so library private implementation,
and the is_const switch is repeated as with my example.  So yes this
is a recurring theme, we could provide a utility to do the necessary, but
that does not seem to be a feature specific to fusion (as opposed to
any other lib that needs to make similar decisions, I believe there is
similar code in phoenix for example).

Possibly we could make this decision at a higher level, in deref proper for
example, but I'm not sure the logic is appropriate in all cases, such as
transform views, were it may be appropriate to return non-const refs from
a deref of a const container.

Cheers
Dan