Re: [boost] Call for interest - BOOST_AUTO_FUNCTION

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-17 22:25:16

At Sun, 17 Oct 2010 14:16:51 -0400,
Matt Calabrese wrote:
> 
> On Sun, Oct 17, 2010 at 5:32 AM, David Abrahams <dave_at_[hidden]> wrote:
> 
> > At Fri, 15 Oct 2010 19:22:16 -0400,
> > Matt Calabrese wrote:
> > >
> > > To see how the macro is used go here: http://codepaste.net/4u34ma
> >
> > Nice!!  Now are you ready to write BOOST_PARAMETER_AUTO_FUNCTION?  :-)
> >
> 
> Ha. You know, I actually considered using Boost.Parameter internally for its
> type template features before opting for just specializations, but for some
> reason I never even thought of trying to support Boost.Paramter
> functions. Perhaps for release 10 :p
> 
> On Sun, Oct 17, 2010 at 5:32 AM, David Abrahams <dave_at_[hidden]> wrote:
> 
> > Questions
> >
> > * The "keywords" are getting a bit long.  Could you think of shorter
> >  names?  Super bonus for finding a way to make them highlight
> >  distinctively ;-)
> 
> 
> I could certainly change requires_expression to requires_expr or anything
> else that makes sense.  I'm not tied to anything in particular
> 
> When you say highlight, do you mean try to reuse more C++ keywords so they
> highlight in IDEs, something like I do with "return" (and I guess "requires"
> if C++ were to eventually get concepts)? 

Something like that.

> I could use "break" instead of
> "end". "explicit" might make sense for explicitly specifying the return type
> as opposed to "result_type", though I feel like the latter may be more
> clear. Maybe I could use "if" instead of "requires". If you have any other
> suggestions, let me know. I'm all for something like that as long as the
> keywords make sense.

Worth trying, all of them.  

> 
> > * is it possible to make all return types lazily computed, so there's
> >  no need for lazy_result_type?  I'm not saying I see how to do this,
> >  but you might :-)
> 
> Definitely. I could make it work like mpl::apply (I think that's a feature
> of apply unless I'm mistaken) and just use ::type if its there, otherwise
> use the type itself. 

But then, how would you return something that happens to have a nested
::type?  Wrap it in identity?

> In the code right now I implement result_type with
> lazy_result_type anyway by wrapping it in mpl::identity.
> 
> > * What is (end) and where is it needed?
> 
> 
> Ah, yeah, I should have been more clear on that. Perhaps I'll make a
> more descriptive error message if you misuse it. "end" is required
> when you want to end a function header such as to either separate
> the declaration from the implementation, or to use the macro with a
> multi-line function. You can only use it if you have explicitly
> specified a return type. You can't use it after a "return", but
> rather, you use it instead of return. If you declare a function with
> "end" you must also define it with "end", otherwise your declaration
> will be for a different function than your definition (ouch!).  One
> reason why you may wish to use "end" even when you're not separating
> declaration from implementation is if you are using
> BOOST_AUTO_FUNCTION only for "requires" or "requires_expression"
> rather than automatic return type deduction, and it's difficult to
> convert your function template to a 1-liner.

Can't you just detect whether "return" was used, and if not, sythesize
the "end" internally?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com