I think it's great how std::begin() and std::end() unify containers and built-in arrays with a clean and simple syntax.
In addition, I think the commitee should include a global std::size() function. This would surely be preferable to the ugly ARRAYSIZE/countof macro hacks which are so commonplace. In his "Notes on Programming" Alexander Stepanov writes - "I made size into a member function in STL in an attempt to please the standard committee. I knew that begin, end and size should be global functions but was not willing to risk another fight with the committee." Thankfully the committee made begin and end global in C++11 but we are still waiting on global size.
I would also make std::front() and std::back() global too.
These additions would make life far easier for all programmers and shouldn't be too difficult to implement.
I would suggest that <utility> is probably the best place for the functions I've mentioned.
Perhaps even a global std::at() function to provide bounds checking for built-in arrays .
I agree that range-for doesn't have much of an advantage over for_each in the presence of lambdas. However, I'm glad range-for was standardized. I agree that range-based STL algorithms and polymorphic lambdas make range-for almost redundant, but they are not standard at the moment. range-for has automatic type deduction today (if it were implemented). Also it is possible to break and continue with range-for which I can't do with for_each, even with range-based STL and polymorphic lambdas.
Personally, using std::for_each with a lambda in VS 2010 is sufficient for most of my needs. I have created my own for_each_n algorithm (I'd love to see something like it in the standard btw) for when I want to only do something with the first, say 10 elements in a range. I couldn't do that with range-for.
You mention that if range-based STL algorithms and polymorphic lambdas were added there would be "little incentive" to use range-for. I agree with you but I still think range-for will be popular as some programmers have the perception that built-in language facilities are superior to library alternatives.
Regarding non-copyable classes, although boost::noncopyable may be easier to use and teach I still feel it is only a partial solution. The problem being that using a base class with private copy constructor and assignment operators makes a class non-POD. I think boost::noncopyable using defaulted and deleted functions would combine the best of both.
Why do you prefer std::for_each over range-based for? Is it because range-for isn't implemented in VS11 (it's not in the dev preview) or is std::for_each faster because of loop unrolling? Or another reason?
Instead of boost::noncopyable howcome C++11 defaulted and deleted functions weren't added. I know it would be slightly more verbose, two lines instead of one to disable copy, but I think they are superior. Lack of time?
P.S binary_search which returns a bool. that made me laugh. lol. Over the years, I wonder how many C++ programmers have rolled their own binary search which returns an iterator? Not the finest moment for the STL!