"Peter Dimov" <pdimov@mmltd.net> wrote in message news:006f01c557b3$934ff320$6f01a8c0@pdimov... | Thorsten Ottosen wrote: | | >> Note that there is no need for an rvalue reference here unless you | >> really want to allow people to change a non-const rvalue in a for | >> loop: | >> | >> for( char& i: MyContainer() ) | >> { | >> ++i; // questionable | >> } | > | > it seems to be very useful if you're chaining algorithms that all | > acts on rvalues. | | Yes, I understand your motivation for using an rvalue reference now. But I | still think that you don't need it. | | template<class C> ... my_view( C && c ) | { | begin(c); // c is lvalue here! | end(c); // ditto | } true. and that part of the proposal is not really specified yet. | > still, we need two version of each function, the && version and the | > const & version. | | No :-) | | The && / const& overloading is only ever used with move. It directs | non-const rvalues to && (safe to move) and everything else to const& (not | safe to move). In your case this would mean that you'll get the const | overload for non-const lvalues. I doubt that you wanted that to happen. doh again :-) so begin()/end() would need to be overloaded for & and const&, just like today. | But we got carried away. | | My main point was that your proposed core extension depends on too many | things in the C++ world to conform to your vision of the future. This can be | acceptable and even desirable in a library proposal, but would be counted | against a core language proposal. A language change should be as | self-contained and as independent of other proposals - language or library - | if you want to increase the chances of its acceptance. In my opinion. you should have seen the version I presented in Redmond then :-) anyway, I should state that no dependency on move-semantics is needed. -Thorsten