[boost] [iterator] [property_map] Enhancement proposals

Subject: [boost] [iterator] [property_map] Enhancement proposals
From: Louis Dionne (louis.dionne92_at_[hidden])
Date: 2012-09-29 12:29:53

Dear boost,

First of all, let me quickly introduce myself as this is my first post here:
I am a 20 years old programming enthusiast with interest for metaprogramming,
functional programming and library design. I also have a strong will to
contribute to open source projects since I love the philosophy behind it and
it is a great way to develop new skills and to work with talented people.

The object of this message is to collect feedback on several enhancement
proposals I have prepared for two existing libraries:

[boost.iterator]
[boost.iterator.accessor_iterator]
The accessor_iterator is an iterator adaptor that returns a reference to a
member of its pointee when dereferenced. I see it as another step in the
direction of easier iterator composition, which has helped me writting less
code in the past.

[boost.iterator.chained_output_iterator]
The chained_output_iterator is an iterator adaptor allowing to apply a
functional transformation to a value before outputing it into another output
iterator. It is much like a function_output_iterator that would forward its
result to another output iterator. It allows for cool stuff like creating a
pipeline of operations without having to create temporary storage.

[boost.property_map]
[boost.property_map.accessor_property_map]
The accessor_property_map is a property map returning a reference to a
member of the key it is given. It is much like the accessor_iterator for
property maps.

[boost.property_map.chained_property_map]
The chained_property_map is a tool for property map composition. It takes
two property maps and uses a value in the first one as a key in the second
one to perform its put, get, and operator[] operations.

[boost.property_map.property_traits]
I feel like the boost/property_map/property_map.hpp header is a little bit
bloated and not quite as modular as it could be. For now, I propose that we
move the code dealing with property_traits into the
boost/property_map/property_traits.hpp header and that we provide
metafunctions to check for adherence to property map types. By providing
an include in the boost/property_map/property_map.hpp header, backward
compatibility is maintained and we simply increase modularity.

All the code is available on github:
https://github.com/ldionne/boost-submissions

To see how each class can be used, you may look at the unit tests for the
corresponding class.

If anything is accepted, I will be pleased to write documentation and examples
for the concerned feature and to integrate it into the existing documentation.

Looking forward to your feedback,

Louis Dionne