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

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-31 22:48:01

At Wed, 13 Oct 2010 10:09:39 -0700,
Steven Watanabe wrote:
> 
>  AMDG
> 
> Sorry for the delayed response.

Back atcha!  Been looking forward to getting back to this thread.

> >> As an example, let's use the fusion::less algorithm.
> 
> I was actually using a simplified version that requires
> both sequences to be the same type.  (And thus the
> same length).  A full lexicographical comparison is
> fine though.
> 
> > Close.  What you need is a refined concept for NonEmptyFusionSequence
> > that includes front_type and pop_front.  Just riffing here, but this
> > could work:
> >
> > concept FusionSequence<class S>
> > {
> >       CompileTimeInt size_type = int_<0>;
> >
> >       constexpr bool empty(const S&) { return size_type::value; }
> >       constexpr std::size_t size(const S&) { return size_type::value; }
> > }
> >
> > auto concept NonEmptyFusionSequence<class S>
> >    : FusionSequence<S>
> > {
> >       FusionSequence next_type;
> >       next_type pop_front(const S&);
> >
> >       typename front_type;
> >       front_type front(const S&);
> >
> >       CompileTimeInt size_type = int_<next_type::size_t::value+1>;
> > };
> >
> > // A shorter way. Because of refinement, this one will only get
> > // used when either S1 or S2 is empty.
> >
> > template<FusionSequence S1, FusionSequence S2>
> >    // a constraint you could add for clarity, but don't need
> >    // requires SameType<int_<0>, int_<S1::size_type()*S2::size_type()>  >
> > concept_map LessThanComparable<S1,S2>
> > {
> >      constexpr operator<(S1 const&, S2 const&)
> >      { return S1::size_type()<  S2::size_type(); }
> > }
> 
> Isn't the extra constraint needed to make sure
> that trying to compare sequences whose elements
> are /not/ LessThanComparable won't silently misbehave?

I see what you mean; I overlooked that issue.  Technically the correct
answer is that I guess it depends on your desired semantics; as I
coded it, it would mean

  make_tuple(1, 2) < make_tuple("a", "b", "c")

is that misbehavior?  Well, I guess it's not what tuple is currently
specified to do, so maybe it is.

> > template<NonEmptyFusionSequence S1, NonEmptyFusionSequence S2>
> >    requires LessThanComparable<S1::front_type,S2::front_type>
> >          &&  LessThanComparable<S1::next_type,S2::next_type>
> > concept_map LessThanComparable<S1,S2>
> > {
> >      operator<(S1 const&  x, S2 const&  y)
> >       { return front(x)<  front(y) || pop_front(x)<  pop_front(y) }
> > }
> 
> Okay.  Here's why I don't like this.
> 
> Suppose that I define a second algorithm with
> exactly the same requirements.  

So the first algorithm is fusion::less.  If you accept the above
concept_maps, fusion::less would just look like:

     template <FusionSequence S1, FusionSequence S2>
       requires LessThanComparable<S1,S2>
     bool less(S1 const& x, S2 const& y)
     {
         return x < y;
     }

> As an example,
> I'll use what fusion::less actually does.  (It doesn't
> quite do a lexicographical comparison.  It truncates
> to the length of the shorter sequence.)  This may
> be slightly contrived, but I'm sure you'll agree that
> there exist algorithms with identical requirements,
> neither one of which can be easily implemented
> in terms of the other.

Granted.

Okay, so that would be

     template <FusionSequence S1, FusionSequence S2>
       requires LessThanComparable<S1,S2>
     bool what_fusion_less_actually_does(S1 const& x, S2 const& y)
     {
         ...
     }

Right?  Same requirements.

> Now, suppose that I want to write a function
> template<FusionSequence S1, FusionSequence S2>
> void foo(S1, S2);
> which calls both of these algorithms.  How can I
> write the requirements for foo?

     template <FusionSequence S1, FusionSequence S2>
       requires LessThanComparable<S1,S2>
     bool foo(S1 const& x, S2 const& y)
     {
         return less(x,y) && what_fusion_less_actually_does(x,y);
     }

> a) requires LessThanComparable<S1, S2> &&
> TruncatingLessThanComparable<S1, S2>
>     Is every function template that calls foo also going to
>     have to list both of these?  This is silly and makes foo
>     difficult to change, because the concept requirements
>     include extraneous information.  Remember that the
>     two sets of types that model these concepts are the same.
> b) Leave it with just FusionSequence.
>     I hope this won't compile unless you have a concept_map
>     LessThanComparable<FusionSequence, FusionSequence>
>     which is a bad idea, as I explained above.
> c) Somehow define a concept that allows both LessThanComparable
>     and TruncatingLessThanComparable to be deduced.  This
>     would be ideal, but I don't have the least idea how to accomplish it.
> d) Something else I haven't thought of?

I don't understand why you'd go down any of those roads.  Am I missing
something?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com