Subject: Re: [boost] [mpl] is_lambda_expression bug?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-10 01:26:56
On Sat, Feb 9, 2013 at 10:12 PM, James Hirschorn <
> Jeffrey Lee Hellrung, Jr.-2 wrote
> > If it's not documented, I don't know what propertiesis_lambda_expression
> > has and what guarantees it makes. Its name suggestssome, I admit, but who
> > knows what the author's intents were? Without someadditional
> > documentation, the code defines its behavior, hence I'd say
> > it'stautologically correct :)I can sympathize if you think the above
> > implies this metafunction should bean auxiliary or detail namespace; I
> > would agree.
> I would think (but I don't really know) that having undocumented functions
> in the main namespaces would itself be a violation of boost policies, even
> if it worked as expected.
AFAIK, it's not a boost policy violation, though I agree it's generally not
On this basis I think I will make a report and see
> what they say.
Can't argue with that.
> Even if it was hidden, it seems like horrible style to have
> is_lambda_expression fail on lambda expressions (there is a documented
> is_sequence metafunction, and there is an is_placeholder in the mpl
> namespace that seems to work as expected).
Yes, I agree that it's poorly named. At least based on your report and my
quick glance at the code.
> > Is this just an FYI, or are you genuinely in need to detecting
> > Boost.MPLlambda expressions?
> Yes, there is a need. I want a function to be instantiated according to its
> template parameters (e.g. one definition if T1 is a lambda_expression and
> another if T1 is a sequence (or is there overlap?)).
Well, one solution is to assume T1 is a lambda expression if it's not a
sequence. Another solution is to implement your own is_lambda_expression
metafunction. Or, who knows, maybe if you continue to troll through the MPL
headers, you'll find what you're looking for :)
Anyways, sorry you didn't get the answer you were probably hoping for.
C'est la vie.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk