|  | Home | Libraries | People | FAQ | More | 
A number of features asked by reviewers and users of Boost.PolyCollection are considered for inclusion into future versions of the library.
        Boost.PolyCollection can be extended to use Boost.TypeIndex
        in RTTI-challenged scenarios. Taking this idea further, it is not unusual
        that some environments (game engines, for instance) provide their own RTTI
        framework: an even more ambitious extension to Boost.PolyCollection would
        then be to make it configurable for user-provided RTTI through some sort
        of traits class specifying replacements for std::type_info
        and typeid.
      
        boost::base_collection requires that stored objects
        be MoveConstructible
        and MoveAssignable;
        unfortunately, it is customary to restrict copying in OOP hierarchies to
        avoid slicing, which would force users to revisit their class definitions
        in order to use Boost.PolyCollection. This can be alleviated by offering
        a configurable traits class where copy and assignment can be defined externally
      
template<typename T> struct copy_traits { void construct(void*,T&&); void assign(T&,T&&); };
        with default implementations resorting to regular placement new and T::operator=.
      
        C++17 introduces parallel
        algorithms, like for instance a parallel version of std::for_each;
        it is only natural then to provide the corresponding Boost.PolyCollection-specific
        algorithms. The segmented nature of polymorphic collections makes
        them particularly amenable to parallel processing.
      
        Closed polymorphism is a kind of dynamic polymorphism
        where the set of implementation types is fixed at definition time: the prime
        example of this paradigm in C++ is std::variant.
        Although boost::any_collection<boost::mpl::vector<>> can act as a sort of replacement
        for std::vector<std::variant<T1,...,TN>>, this is in fact more similar to
        a std::vector<std::any>, and a collection class boost::variant_collection<T1,...,TN>
        could be designed to better model closed polymorphism and take further advantage
        of the fact that implementation types are fixed (for instance, internal virtual
        calls can be completely eliminated). From a conceptual point of view, this
        would require introducing a new ClosedPolymorphicCollection
        notion and renaming the current PolymorphicCollection
        model to OpenPolymorphicCollection.
      
        Users have expressed interest in polymorphic collections where elements are
        kept ordered within their segment and optionally duplicates are excluded,
        much like boost::flat_set/boost::flat_multiset
        do over their internal data vector. The open question remains of whether
        these collections should also guarantee some order between segments (current
        ones don't) to allow for the definition of container-level operator::<
        and related operators.