[boost] property_map/compose_property_map get() return type

Subject: [boost] property_map/compose_property_map get() return type
From: Brook Milligan (brook_at_[hidden])
Date: 2017-10-31 02:58:08

I am trying to understand the logic behind the get() function for the Boost compose_property_map, which is defined in boost/property_map/compose_property_map.hpp.

The document states the following:

        This property map is an adaptor that composes two property map. The new property map will of the same model as FPMap.

I interpret these two sentences to mean that the category, value_type, and reference types of the composition will be the same as those for FPMap, while the key_type will be the same as for GPMap.  Thus, I expect that get(composition,gkey) should return the same type that get(fpmap,fkey) would.

However, the implement does not follow this expectation, which leaves me puzzled.  The following is the relevant portion of the code:

template <typename FPMap, typename GPMap>
class compose_property_map
{
public:
    typedef typename boost::property_traits<FPMap>::reference reference;

    // return type of get():
    // if (reference is not a ref)
    //     value_type
    // else if (reference is const)
    //     reference
    // else
    //     const value_type&
    inline friend typename boost::mpl::if_<
        boost::mpl::not_< boost::is_reference<reference> >,
        value_type,
        typename boost::mpl::if_<
            boost::is_const<reference>,
            reference,
            const value_type&
            >::type
        >::type
    get(const compose_property_map &m, const key_type &k) {
        return get(m.f, get(m.g, k));
    }

Notice the comment and the selection of the return type.  The result is always a value_type or _const_ reference, irrespective of the reference type of FPMap.

Consequently, the information advertised as the reference type, which is the same as that of FPMap, is incorrect, and get() does not return a simple composition of the two property maps as described in the documentation.

What is the rationale for this behavior?  It seems that there must be a reason to go to the great lengths to second guess what FPMap is doing, rather than simply doing what the documentation says should occur, but I fail to see it.

I look forward to any clarification.

Thanks a lot.

Cheers,
Brook