Meantime it again highlights that a core language change to allow anonymous fns is needed so this whole mechanism of BLL can go away.
// PROPOSED CHANGE IN SOME FUTURE PAPER
unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, long (long lhs, X const &rhs) // inline fn with no name. { return lhs + rhs.count; } );
I was hoping the syntax would be: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL,{ return _1 + _2.count; } ); With the option of this when you want different names: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, lambda(lhs,rhs){ return lhs + rhs.count; } ); Incidentally, frustrated with the limits of BLL syntax I've moved to using macros for the most common cases in one of my programs (e.g. for each element in a specific container). I went through and replaced all std::for_each calls, and all for/while loops. The macro looks very much like the syntax above and the code ended up shorter, clearer, and also uncovered some bugs: it turns out I'd written a loop with "i!=c.begin()" instead of "i!=c.end()". The macro always gets that right. Max Motovilov wrote:
Yeah, but do you propose to make local names visible inside the anonymous function, or not? If you do, you open a big can of worms for implementations (recursive nested functions, need I say more?)
I think local names visible inside the anonymous function is the expected behaviour. Can you say more about the potential problems (or point me to a paper/discussion if this is well-discussed somewhere else)? Darren