"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:d53uss$p3n$1@sea.gmane.org... | 1. Rvalues support | I agree it's cool and "magical" - the way you added support for rvalues. But | I believe it's actually misplaced efforts. IMO support for rvalues brings | more harm than advantage. I could accidently or mindlessly (using some | global replacement in sources, for example) introduce rvalue in | BOOST_FOREACH statement and compiler wouldn't warn me. Now I am paying for | an unnessesary copying. while exist perfectly good alternative that doesn't | require it: | | my_collection_type my_function(); | ... | | my_collection_type const& v = my_function() | | BOOST_FOREACH(... , v ) | { | } | | In addition eliminating rvalues support will signicantly simplify | implementation and as a result speed up compilation. hm...that won't save you anything AFAICT. | 2. Usage of Boost.Range | | I understand why FOREACH is using Boost.Range, but: | a) In many (most) cases I (and any other developer now) working with stl | containers and wouldn't need any extra help from boost.range for FOREACH to | work properly. things like pair<iterator,iterator> are very common...just look at BGL. besides, you need a way to make your own collection work with foreach. | b) Usage of Boost.Range introduces an extra dependency on ... Boost.Range | and everything it depends on in its' turn (including all portability | limitations). I for one couldn't afford this dependency, | c) Usage of Boost.Range adding a level of indiration and slightly | complicate am implementation so.? the standard containers part of it is pretty portable. -Thorsten