On Sat, Feb 9, 2013 at 10:12 PM, James Hirschorn < james.hirschorn@hotmail.com> wrote:
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 good practice. 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. - Jeff