| Home | Libraries | People | FAQ | More

## Future work

A number of features asked by reviewers and users of Boost.PolyCollection are considered for inclusion into future versions of the library.

### Alternative RTTI systems

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`.

### Copy traits

`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=`.

### Parallel algorithms

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.

### `variant_collection`

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`.

### Ordered polymorphic collections

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.