Boosters, I am considering my position on this patch. I can see that it is pleasant syntactic sugar, but the reason I consciously omitted this was that it suffers from combinatorial explosion. I feel that one of the nice aspects of the current Boost.Range design is that it reduces combinatorial explosion by breaking down items into their constituent orthogonal parts. However I am reconsidering since there are a growing number of people requesting this feature, and perhaps the pragmatic convenience outweighs the slightly theoretical design concern. I need to make some effort to tackle some of the Boost.Range suggestions that have been accumulating during a period of ill health. I apologize for slow responses. It is important, to me, to make interface changes that I do not later regret. This needs some further investigation and thought. Neil Groves On Fri, Mar 16, 2012 at 10:54 AM, Robert Jones <robertgbjones@gmail.com>wrote:
On Wed, Oct 12, 2011 at 4:03 PM, Maxim Yanchenko <maximyanchenko@yandex.ru>wrote:
Hi Jeff,
Of course this works, as well as STL iterator-based loops versus BOOST_FOREACH. As I said, this is just a syntactic sugar that makes the code cleaner,
and
it does this for quite a frequent case when you call element's member function.
I'd like to see this patch make it into a release too, despite Jeff's misgivings. While I can appreciate Jeff's comments about consistency of Boost interfaces in different libraries, the Boost Range adaptors are absolutely all about brevity and clarity of exposition, and as such seem especially to benefit from this syntactic sugar.
Is this patch's appearance in a release 'in progress'? Anyone?
Thx,
- Rob.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost