Re: [boost] [guidelines] why template errors suck

Subject: Re: [boost] [guidelines] why template errors suck
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-09-28 22:54:01

On Tue, Sep 28, 2010 at 9:14 PM, David Abrahams <dave_at_[hidden]> wrote:
> At Tue, 28 Sep 2010 15:36:30 -0400,
> Daniel Walker wrote:
>>
>> >> Was there something unsatisfying about the solution I posted in
>> >> http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 ?
>> >
>> > Nope, I just missed it.
>>
>> Oh wait! I think I have another example that's more truthy. :) I'll
>> use Boost.ConceptCheck to flesh it out. Let's define the concept of an
>> AdditivePair to represent the arguments to binary addition. To model
>> the concept a type needs to support first(x), second(x) and add(x) for
>> an object x where all three functions have integer values.
>
> <snip>
>
>> We can now adapt std::pair<int,int> to model the AdditivePair concept.
>>
>
> <snip>
>
>> And we can also adapt int to model the AdditivePair concept; i.e. int
>> is an additive pair where the second member is 0.
>
> <snip>
>
>> That seems pretty natural to me.
>
> Do you honestly think it's as truthy as the solution I offered?

Oh, I didn't mean to compare my example to yours. I only meant mine
was more truthy than the previous example in the thread that used
first(x) and second(x). Describing the concept in terms of pairs is
more natural when you consider that an addition operation always has a
first and second argument. Your solution comes at it from a different
angle, which is also plenty truthy: the pairs are being reduced to int
values, so in that sense IntValued naturally arises as a concept.

>
> IMO it's a slight improvement over the list's previous offering, but
> making int model AdditivePair is still an odd contortion.
> AdditivePair still doesn't represent a real abstraction that you'd use
> anywhere else.  By contrast, you could make int model ComplexNumber;
> that would make real sense and be useful outside of this toy problem.
>
> Are you just exploring, or is there another reason we keep heading
> down this path?

Just exploring. :) It's a good toy problem to see how concepts can
express the type requirements of a function, even when the types are
seemingly unrelated like int and pair. It works in this case, because
of the semantics of addition, so it also illustrates how semantics are
important to concepts, as you have stressed.

Daniel Walker