|
Boost : |
Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-10-18 17:55:44
On Mon, Oct 18, 2010 at 12:25 PM, Dean Michael Berris <
mikhailberis_at_[hidden]> wrote:
> But then how does the compiler do something like deduce the return
> type of a lambda?
>
> auto f = [](int x) { return x * 2; }
>
> Shouldn't the same mechanism be available in normal function
> declarations even without the computation of the return type? I would
> love to be able to write functions that look like:
>
> auto f(int x) {
> return x * 2;
> }
Ah! This just made me realize that it should be possible (and easy) with the
macro to support multi-line void functions much like lambdas do.
What I'm proposing is that I support syntax something along the lines of
this:
template< typename T >
BOOST_AUTO_FUNCTION( ( foo( T& arg ) )
( do // "do" is just the parameter ID like "requires" and "return"
++arg;
std::cout << arg;
// Do as much stuff as you want
))
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
}();
}
That should work, correct? 1-line functions should get the properly deduced
return type still, but now multi-line void functions are supported in the
exact way that they are with respect to lambdas. Since the multi-line
function would be void, the main benefit of this would be that since the
statements all appear in the return type of the encapsulating function,
definitions that would fail to instantiate are now caught by SFINAE (someone
correct me if I'm wrong here, I'm not certain off-hand that the extended
SFINAE rules apply to statements in a lambda function).
Does anyone see something that I am missing? This should probably work,
correct?
I'm also not sure that "do" would be a good idea to use in this context, as
it may end up being confusing.
-- -Matt Calabrese
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk