Re: [boost] Call for interest - BOOST_AUTO_FUNCTION

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-10-18 21:10:01

On Mon, Oct 18, 2010 at 5:55 PM, Matt Calabrese <rivorus_at_[hidden]> 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