I'd like to know a little more about the design rationale for property maps, specifically the (maybe implicit) decision not to overload operator[] with respect to constness. The design leads to a situation that is, in some respects, at odds with convention. The most obvious point of conflict is put_get_helper. In fact, I wouldn't be surprised if the decision not to overload operator[] was simply a consequence of writing put_get_helper. (Pure speculation.) template struct put_get_helper { }; template R get( put_get_helper const& map, K const& key ); template void put( put_get_helper const& map, K const& key, V const& value ); In contrast with standard containers, the constness of the property map isn't correlated to the constness of its elements. I wonder why the above wasn't written as template struct put_get_helper { }; template R get( put_get_helper& map, K const& key ); template C get( put_get_helper const& map, K const& key ); template void put( put_get_helper& map, K const& key, V const& value ); Another point of conflict is the property_map traits class, with its nested 'type' and 'const_type'. Doesn't convention suggest that 'type const' is the appropriate type for a non-mutable property map? My initial statement was that the design leads to a situation that is *in some respects* at odds with convention. When property maps are viewed, not as first class containers of their data, but as having more-or-less the same status as container iterators, the situation clarifies. I suppose that must have been the author's intent. // A deficient, but harmless implementation of put(), get() for iterators. template struct put_get_helper { }; template R get( put_get_helper const& it, K const& key ); template void put( put_get_helper const& it, K const& key, V const& value ); // Parallel to property_map. template<class Container> struct container_iterator { typedef typename Container::iterator type; typedef typename Container::const_iterator const_type; };