On 5/19/2010 2:25 PM, Jeremiah Willcock wrote:
On Wed, 19 May 2010, Eric Niebler wrote:
On 5/19/2010 2:08 PM, Marco wrote:
I am a bit surprised by:
// These should be ambiguous. BOOST_MPL_ASSERT((is_same<deduce_domain3<DD1, DD0, DD0>::type, not_a_domain>)); BOOST_MPL_ASSERT((is_same<deduce_domain3<DD0, DD1, DD0>::type, not_a_domain>)); BOOST_MPL_ASSERT((is_same<deduce_domain3<DD0, DD0, DD1>::type, not_a_domain>));
I was expecting something like: BOOST_MPL_ASSERT((is_same<deduce_domain3<DD1, DD0, DD0>::type, default_domain));
Am I missing something ?
This is a tricky case, and to understand why I want that result, you need to know what proto uses domains for. In proto, you put an expression in a domain to give it certain domain-specific behaviors. (E.g. lambda expressions should have an operator() that evaluates the lambda.) However, there are no domain-specific behaviors to the default_domain. (E.g. "42" is in the default_domain. Obviously, it has no domain-specific behavior itself, but "lambda::_1 + 42" should be in the lambda domain.)
If you combine two expressions in different domains, and the only super-domain they have in common is default_domain, then that would effectively strip all domain-specific behavior from the new expression. IMO, this would be surprising. Instead, I'd rather make this case ambiguous -- proto doesn't know what domain-specific behaviors to give the new expression so it gives up.
I acknowledge that it is a special case and that this result doesn't follow naturally from the other rules.
How do the rules for default_domain (and domains derived from it) fit into that picture? Expressions from different domains not derived from default_domain produce not_a_domain in the case of conflicts,
Right.
while a pair in which one element is derived from default_domain will always choose that element as the domain of the new expression.
Here, you mean "the other element" -- that is, the domain that is not a sub-domain of default_domain. The family of domains rooted at default_domain is weaker than all others. (I want this behavior for unified placeholders. Consider that _1 should be a lambda, but it should combine freely with expressions in other domains.)
In my implementation, if both domains derive from default_domain but are otherwise incompatible, the result will be default_domain,
That's not right for the reason I stated above. And that's the case that hung me up for a while.
but normal domains do not derive from default_domain and so end up with the not_a_domain behavior in the case of conflicts.
This part is right. -- Eric Niebler BoostPro Computing http://www.boostpro.com