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-17 02:39:52

There is a link to the current implementation at the bottom of this reply if
anyone wants to play with it and not read the big block of text.

On Sat, Oct 16, 2010 at 9:14 AM, Sebastian Redl <
sebastian.redl_at_[hidden]> wrote:
>
> Well, Clang currently doesn't, but hopefully that will change soon.

What I meant was that all compilers which claim to support trailing return
types already support variadic macros, but not necessarily the other way
around. No trailing return type support is pretty much a complete show
stopper for the macro anyway, so a lack of variadic macros at that point
wouldn't make things any worse.

Either way, I'd rather just not support compilers in this odd state of flux
between current C++ and C++0x, since trying to support a compiler without
variadic macros would make using the macro more complicated and would imply
a breaking change to the interface should the workaround ever stop being
supported, unless I were to maintain two separately named macros.

Anyway, the macro as I've described is now just about done -- I need to
write up some documentation and more tests, but it should be usable, though
likely only in GCC. Despite it being a gigantic macro hack, I've put a lot
of effort into making decent error reporting (don't try it on anything other
than GCC though heh). In order to avoid the compiler spewing out a bunch of
confusing errors when you misuse it, I've gotten it to detect some possible
user mistakes, including what I'd imagine would be common typos (such as
require or required instead or requires). As well, on macro-use error
detection, the macro does what is necessary to output code up to that point
in a manner that will compile without error, but then static asserts telling
the user exactly what's wrong and how to fix it. Finally, it "eats" all of
the further parenthesized macro invocations so you get no additional errors
related to BOOST_AUTO_FUNCTION. Of course, all of this only applies if I am
able to detect the problem, otherwise you will still get some messy errors.

I have some ideas for future direction already that may prove to be very
useful, though I likely won't implement for a little while. Probably the
most useful new feature would be to allow users to specify requirements for
the automatically deduced result type. For instance, you may be writing a
function template where you don't write an explicit return type since you
want it to be automatically deduced by the return expression, however, you
still wish to require the return type to be some kind of random access
iterator, or you may wish to check if the return value could be used in
particular expressions (similar to requires_expression as is in the current
macro). If any of these conditions aren't met, then substitution will fail
and you will see a single error. All of this combined with automatic return
type deduction and arbitrary expression requirements would ordinarily be
very tricky to pull off in C++0x without support, but the macro would make
it embarrassingly trivial.

Other new features I'm considering are return_ref, return_value, and return
rvalue_ref, which would augment the automatically deduced return type
accordingly.

For instance:

template< class L, class R >
BOOST_AUTO_FUNCTION( plus_eq( L& left, R const& right ) )
(
  return_ref left += right
)

would return a reference to left, whereas

template< class L, class R >
BOOST_AUTO_FUNCTION( plus_eq( L& left, R const& right ) )
(
  return_value left += right
)

would return left by value

Unfortunately, because of the way development unfolded, I started with a
design that gets increasingly more complex as I support more argument kinds
(even adding requires, requires_expression, etc. made it very redundant and
almost unmaintainable). Before I add anything else, I'll need to redesign it
in the way I should have done from the start, but I think I'll stop for the
time being anyway and add docs/more tests then request review.

To see the currently disgusting hack in all its glory:
http://codepaste.net/vrn9gm

Again, you have been warned to only try it in GCC. Look to my earlier
replies in the thread for basic usage. Let me know if there is anything
blatantly wrong, which there probably is as it's barely tested at all at
this point. If you want to see some of the "pretty" error reporting I put
in, try making an auto function that has two or more "( requires
your_condition_here )", or write "require" instead of "requires".

I don't know why I'm having so much fun with this, it's really pretty sad.

I'll try to clean everything up, split it up into multiple files, and get it
and some docs and tests up on the sandbox in the next couple of days.

-- 
-Matt Calabrese