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@getdesigned.at> 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