Boost logo

Boost :

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:
> >
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at