[mpl] is_lambda_expression bug?
The compile-time assertion fails in the following program. I have tried with more than one version of boost including 1.53. Is it a bug? Shall I report it? -------------------------------------------------- #include <boost/mpl/assert.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/plus.hpp> namespace mpl = boost::mpl; struct MetafunctionClass { template<typename T1, typename T2> struct apply { typedef typename mpl::plus<T1,T2>::type type; }; }; BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>)); int main(int argc, char * argv[]) { } --------------------------------------------------
On Fri, Feb 8, 2013 at 9:04 AM, James Hirschorn <james.hirschorn@hotmail.com
wrote:
The compile-time assertion fails in the following program. I have tried with more than one version of boost including 1.53.
Is it a bug? Shall I report it?
--------------------------------------------------
#include <boost/mpl/assert.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/plus.hpp>
namespace mpl = boost::mpl;
struct MetafunctionClass { template<typename T1, typename T2> struct apply { typedef typename mpl::plus<T1,T2>::type type; }; };
BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>));
int main(int argc, char * argv[]) { }
I can't find any documentation for is_lambda_expression...though I didn't look very hard...is it part of the public API? - Jeff
Jeffrey Lee Hellrung, Jr.-2 wrote
I can't find any documentation for is_lambda_expression...though I didn't look very hard...is it part of the public API?
I do not believe it is in the documentation. But since it's part of the public interface shouldn't it be required to work correctly? -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-is-lambda-expression-bug-tp4642509p46... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Fri, Feb 8, 2013 at 1:17 PM, James Hirschorn <james.hirschorn@hotmail.com
wrote:
Jeffrey Lee Hellrung, Jr.-2 wrote
I can't find any documentation for is_lambda_expression...though I didn't look very hard...is it part of the public API?
I do not believe it is in the documentation. But since it's part of the public interface shouldn't it be required to work correctly?
Can you point to something that indicates it is in fact part of the public interface? If it's not documented, I don't know what properties is_lambda_expression has and what guarantees it makes. Its name suggests some, I admit, but who knows what the author's intents were? Without some additional documentation, the code defines its behavior, hence I'd say it's tautologically correct :) I can sympathize if you think the above implies this metafunction should be an auxiliary or detail namespace; I would agree. Is this just an FYI, or are you genuinely in need to detecting Boost.MPL lambda expressions? - Jeff
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?)). -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-is-lambda-expression-bug-tp4642509p46... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
Jeffrey Lee Hellrung, Jr.-2 wrote
On this basis I think I will make a report and see
what they say.
Can't argue with that.
I'm now convinced it is a bug, because mpl::transform uses mpl::is_lambda_expression for the exact same purpose as my application, and it clearly assumes that is_lambda_expression behaves according to its name. I will make an example to submit with the report.
Well, one solution is to assume T1 is a lambda expression if it's not a sequence. ...
This is currently how e.g. mpl::transform behaves, but it's incorrect because a class can be both a sequence and a lambda expression in which case it is supposed to be treated as an operator. -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-is-lambda-expression-bug-tp4642509p46... Sent from the Boost - Dev mailing list archive at Nabble.com.
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.
Edward Diener-3 wrote
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.
I verified that it works correctly with the example I gave. I will use this for now, and perhaps it should be shared with mpl ... -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-is-lambda-expression-bug-tp4642509p46... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mon, Feb 11, 2013 at 10:44 PM, James Hirschorn < james.hirschorn@hotmail.com> wrote:
Edward Diener-3 wrote
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.
I verified that it works correctly with the example I gave. I will use this for now, and perhaps it should be shared with mpl ...
+1 - Jeff
On 02/12/2013 01:44 AM, James Hirschorn wrote:
Edward Diener-3 wrote
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.
I verified that it works correctly with the example I gave. I will use this for now, and perhaps it should be shared with mpl ...
tti depends on mpl so it probably belongs in mpl.
Hi James, James Hirschorn wrote:
The compile-time assertion fails in the following program. I have tried with more than one version of boost including 1.53.
Is it a bug? Shall I report it?
I agree with Jeff, that this isn't really part of the public interface -- I can't find docs either. The metafunction itself appears to detect placeholder expressions*: i.e., expressions involving arg<N> or mpl::bind<>, which it obviously wouldn't in your code. The following lines work: BOOST_MPL_ASSERT_NOT((mpl::is_lambda_expression<MetafunctionClass>)); BOOST_MPL_ASSERT((mpl::is_lambda_expression<mpl::plus<mpl::_1,mpl::_2> >)); Though it would be unwise to depend on it. HTH, Nate * http://www.boost.org/doc/libs/1_53_0/libs/mpl/doc/refmanual/placeholder-expr...
Nathan Crookston wrote
I agree with Jeff, that this isn't really part of the public interface -- I can't find docs either.
It is part of the public interface (whether or not intentionally) because my client code can access it. Being undocumented is another issue.
The metafunction itself appears to detect placeholder expressions*: i.e., ...
Then it should be called is_placeholder_expression -- View this message in context: http://boost.2283326.n4.nabble.com/mpl-is-lambda-expression-bug-tp4642509p46... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (4)
-
Edward Diener -
James Hirschorn -
Jeffrey Lee Hellrung, Jr. -
Nathan Crookston