On 8 September 2016 at 15:20, John
Thanks, Why does boost range require a public non-const iterator that will never be used, yet the std:: framework does not? Is this intentional?
It is intentional. The range for each for example came in C++11 and relies heavily on auto for type deduction (http://en.cppreference.com/w/cpp/language/range-for). Boost.Range Concepts were designed long before C++11 and therefore had to include to determine the type from a const and mutable range that worked with std:: containers. Additionally we wanted a design that could take other collections such as MFC/ATL containers (just as an example) and make them model the Boost.Range Concepts non-intrusively. Of course, the std:: algorithms do not directly work with ranges, and this particular design issue is handled by the function to extract the iterator. The std:: containers do use the const_iterator and iterator types and have appropriate begin and end overloads. The Range Concepts very closely follow the design of the standard containers in this respect. There does remain a design choice to allow the old Concepts to have combine newly defined Concepts that make the granularity more fine grained. The cost of this, is the large increase in the number of Concepts, and the consequent increase in complexity in formally defining the algorithms. This appears to be a recurring problem with Concept-based design. It seems similar to the issues originally experience with traits where the combination of what were effectively meta-functions was found limiting as the composition was often not correct for different contexts. I believe the general consensus is now to have orthogonal meta-functions, and then it is a matter of debate whether one continues to have traits to combine the meta-functions producing a layered API. I suspect similarly decomposing Concepts into their minimal orthogonal parts results in the most composable design, but at the cost of API specification complexity which consequently results in a steeper learning curve. I'll think about this some more to see if something can be done to make this better while remaining backward compatible. Regards, Neil