of "Conditional Implementation" vs "Assertive Input Validation"

[Jacob Carlborg]

On 2012-07-23 16:47, Andrei Alexandrescu wrote:

> The assertive input validation has the problem it prevents an overload
> outside of std.algorithm from working.
>
> I think we should focus here on the compiler giving better information
> about which part of the Boolean constraint failed.

I would like to have something like this:

constraint InputRange (Range)
{
     alias ElementType!(Range.init) E;

     @property bool empty ();
     void popFront ();
     @property E front ();
}

constraint ForwardRange (Range) : ForwardRange!(Range)
{
     E save ();
}

constraint BidirectionalRange (Range) : ForwardRange!(Range)
{
     void popBack ();
     @property E back ();
     @property E front ();
}

It would be even better if the Range parameter and the ElementType could 
be handled automatically:

constraint BidirectionalRange : ForwardRange
{
     void popBack ();
     @property ElementType back ();
     @property ElementType front ();
}

And then to use the constraints, like this:

auto filterBidirectional (alias pred, Range : 
BidirectionalRange!(Range)) (Range range);

Or even better if this would be possible:

auto filterBidirectional (alias pred) (BidirectionalRange range);

I know that others have had similar ideas. In these cases I think the 
compiler should be able to give clear and proper error messages when 
something fails to match because now the range constraints/interfaces 
have names. Something like "Foo doesn't match BidirectionalRange" or 
similar.

-- 
/Jacob Carlborg