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 }
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. 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.