On 2/10/2013 1:12 AM, James Hirschorn 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. On this basis I think I will make a report and see what they say. 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).
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?)).
In the latest version of tti on the trunk, I have an is_lambda_expression metafunction as a detail of the implementation. You can find it at tti/detail/dlambda.hpp. I use it at one point in the implementation when introspecting a nested type and allowing the user to optionally apply a lambda expression when found, a suggestion made by Jeffrey Hellrung when tti was reviewed.