On Mon, Oct 18, 2010 at 5:55 PM, Matt Calabrese <rivorus@gmail.com> wrote:
It would be implemented by internally doing something similar to this:
auto foo( T& arg ) -> decltype( [&] { ++arg; std::cout << arg; // Do as much stuff as you want }() ) { return [&] { ++arg; std::cout << arg; // Do as much stuff as you want }(); }
Can someone using VC++ or any compiler that claims to support lambdas test this out? GCC can't compile it all -- I'm curious if anything can yet. Also, here are the new parameter IDs -- I've made them all keywords as per Dave's suggestion: what were "result_type" and "lazy_result_type" are now both just "explicit" which is always lazy and yields the type being passed if it doesn't have a ::type (this may change). what was "requires" is now "if" what was "requires_not" is now simply "not" what was "requires_expression" is now "try" what was requires_expressions" is also now "try" (try always takes a preprocessor sequence of expressions now) "return" is still "return", however it will likely be changed to use the lambda function trick meaning that you can include a semicolon (the semicolon can be optional since I could add one inside the macro -- if the user provided one it'd just be an empty statement at the end of the function, otherwise it would end the return statement). This is good because if the lambda version doesn't work on your compiler, I can just use the old implementation and you'd still be able to use "return", though you'd be required to not end it with a semicolon. For maximum portability you'd just never use a semicolon for the time being. Hopefully this shouldn't be an issue for too long anyway, but I wouldn't get my hopes up. I'll likely use "do" for the multi-line trick. I haven't yet decided what I'd use for the eventually-to-be-implemented checking of return type requirements. Possibly "catch" but that's sort of a stretch. Another possibility might be something like the two word ID "continue if". If you want to suggest IDs, two word IDs should be fine as long as the first word in the phrase isn't already used as a 1-word ID. For instance "continue if" and "continue not" together are unambiguous, but "if continue" would not be okay because I wouldn't be able to know if I should look ahead or not after the "if" (and erroneously looking ahead would have unpredictable behavior -- most-likely an odd compile error). -- -Matt Calabrese