Re: [boost] [challenge!] find a common domain

Subject: Re: [boost] [challenge!] find a common domain
From: Eric Niebler (eric_at_[hidden])
Date: 2010-05-19 17:21:56

(Please don't top-post.)

On 5/19/2010 2:08 PM, Marco wrote:
> On Wed, 19 May 2010 08:02:56 +0200, Eric Niebler <eric_at_[hidden]> wrote:
<snip>
>>
>> Your job: implement the deduce_domain3 template that finds the common
>> domain of 3 domains. You're allowed to use decltype, but you get bonus
>> points for a solution that doesn't. Bonus also for instantiating fewest
>> templates. The challenge is for the ternary case, but your solution
>> should scale to N domains. If your solution is better than mine, I'll
>> use it in Proto and credit you!
>>
>> Good luck.
>>
>> P.S. I haven't checked my solution in yet, so you can't look in trunk
>> and cheat. ;-)
>
>
> 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.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com