of "Conditional Implementation" vs "Assertive Input Validation"

[Jacob Carlborg]

On 2012-07-23 22:28, monarch_dodra wrote:

> My fear is that no matter how you look at it, the compiler just doesn't
> know which overload you want to call. If the compiler could generate
> messages about why each overload was not satisfactory, and it would have
> then to generate messages about each and every possible overload,
> including the ones that you obviously didn't want. Things would be
> better, but probably over-verbose :/
>
> My thought was not to remove conditional implementations entirely, but
> rather to compliment them:
>
> I think, for example, this would be perfect for equal:
> "Takes two input ranges, and compares them with pred":
> Notice that the english input condition here is merely "two input
> ranges". If the range elements don't actually compare, it does not mean
> you did not fulfill the "input contract", but rather that you did not
> fulfill the "implementation requirements".
>
> equal(alias pred = "a == b", R1, R2)(R1 range1, R2 range2)
>    if (isInputRange!R1 && isInputRange!R2)
> {
>    assert(is(typeof(BinaryPred!pred(r1.front, r2.front))), "equal:
> elements are not predicate comparable");
>    ...
> }

That looks even more horrible then the current std.algorithm. We 
shouldn't have to add _more_ of these checks, rather remove. The 
compiler should help the developer, not the other way around.

I think the signatures in std.algorithm are already too complicated and 
verbose and they still don't protect from the horrible template errors 
that template constraints were supposed to help avoid.

-- 
/Jacob Carlborg