I've been putting my nose in std.algorithm recently, specifically, requirements of algorithms.

I must say I'm a big fan of conditional implementations. Given the genericity of templates (!), it can be very hard to overload them correct without conditional implementation. It is a really useful language feature

That said, more often than not, they are also used to validate input. While this is a good thing, when a developer DOES try to call an algorithm with invalid input, he is greeted with the cryptic:
"Error: template foo does not match any function template declaration"
Followed by the (potentially long) list of candidates.
More often than not, the conditional implementations are actually quite complicated, and contain up to 5 or 6 different conditions.

The worse part is that the developer has no idea _which_ condition he has violated.

This is a shame, since most of the time, the conditions are not necessary for disambiguation, and a static assert would work just as well, and be more verbose.

Simple example:
minPos doesn't shouldn't operate on infinite ranges. compare:
Range minPos(Range)(Range R1) if (is(inputRange!Range) && !isInfinite!Range) {...}
vs
Range minPos(Range)(Range R1) if (is(inputRange!Range)
{
    static assert(!isInfinite!Range, "minPos cannot operate on infinite ranges.")
    ...
}

Now, if a developer ever accidentally calls minPos with an infinite range, he gets slapped in the face with a very explicit compilation warning. This (I think) is great, because the "isInfinite" test is really just an implementation detail.

inputRange is really the input condition of the range, and should stay conditional.

--------
How do you feel about "assertive input validation" vs "conditional implementation"?

Is this something you'd like to see more of in algorithm?

On Monday, 23 July 2012 at 11:10:39 UTC, monarch_dodra wrote:

> Is this something you'd like to see more of in algorithm?

Yes! Improving error messages is very important. Maybe we find a better solution on compiler level but in the meantime [not only] std.algorithm will benefit from your solution.

On 2012-07-23 13:10, monarch_dodra wrote:
> I've been putting my nose in std.algorithm recently, specifically,
> requirements of algorithms.
>
> I must say I'm a big fan of conditional implementations. Given the
> genericity of templates (!), it can be very hard to overload them
> correct without conditional implementation. It is a really useful
> language feature
>
> That said, more often than not, they are also used to validate input.
> While this is a good thing, when a developer DOES try to call an
> algorithm with invalid input, he is greeted with the cryptic:
> "Error: template foo does not match any function template declaration"
> Followed by the (potentially long) list of candidates.
> More often than not, the conditional implementations are actually quite
> complicated, and contain up to 5 or 6 different conditions.

I think this is really a problem with std.algorithm.

-- 
/Jacob Carlborg

It certainly makes sense.  Maybe the long term solution would be a way to embed those assertions in the conditions, but in the meantime the proposal would alleviate the error message issue.  I know I've often enough stared long and hard at a volume of template instantiation errors waiting for the real mistake to jump out at me.

----------

And for the curious, what I mean by embedding assertions in the conditions is quite literally what it sounds like:

Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!Range, "minPos cannot operate on infinite ranges." )
{
    ...
}

In which case the compiler would merge the condition expressions of the assertions into the if-condition, and remember the message strings associated with them.

On Mon, Jul 23, 2012 at 1:44 PM, Chris NS <ibisbasenji@gmail.com> wrote:

> And for the curious, what I mean by embedding assertions in the conditions is quite literally what it sounds like:
>
> Range minPos ( Range ) ( Range R1 )
> if( is( inputRange!Range ) )
> assert( !isInfinite!Range, "minPos cannot operate on infinite ranges." )

Would it be possible to create a If / Assert template that returns (er, becomes) true if the condition is true, and static asserts if not ?

template Assert(bool condition, string message)
{
    static if (condition)
        enum Assert = true;
    else
        static assert(false, message);
}

void foo(T,U)(T t, U u) if (is(T == int) && Assert!(isIntegral!U, "U
must be an integer type"))
{}


void main()
{
    foo(1,"a");
}

Seems to work (tm).

On 23-Jul-12 17:29, Philippe Sigaud wrote:
> On Mon, Jul 23, 2012 at 1:44 PM, Chris NS <ibisbasenji@gmail.com> wrote:
>
>> And for the curious, what I mean by embedding assertions in the conditions
>> is quite literally what it sounds like:
>>
>> Range minPos ( Range ) ( Range R1 )
>> if( is( inputRange!Range ) )
>> assert( !isInfinite!Range, "minPos cannot operate on infinite ranges." )
>
> Would it be possible to create a If / Assert template that returns
> (er, becomes) true if the condition is true, and static asserts if not
> ?
>

Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and they are supposed to.

> template Assert(bool condition, string message)
> {
>      static if (condition)
>          enum Assert = true;
>      else
>          static assert(false, message);
> }
>
> void foo(T,U)(T t, U u) if (is(T == int) && Assert!(isIntegral!U, "U
> must be an integer type"))
> {}
>
>
> void main()
> {
>      foo(1,"a");
> }
>
> Seems to work (tm).
>


-- 
Dmitry Olshansky

On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> Will explode every time a constraint is tested?
> After all constraints do fail so that other function is picked up and they
> are supposed to.

Damn, you're right.

On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>
>> Will explode every time a constraint is tested?
>> After all constraints do fail so that other function is picked up and they
>> are supposed to.
>
> Damn, you're right.

To be fair, it explodes as often as the if (isInputRange!T){static assert(!isInfinite!T);} does.

-- 
Simen

On 23-Jul-12 18:07, Simen Kjaeraas wrote:
> On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud
> <philippe.sigaud@gmail.com> wrote:
>
>> On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky
>> <dmitry.olsh@gmail.com> wrote:
>>
>>> Will explode every time a constraint is tested?
>>> After all constraints do fail so that other function is picked up and
>>> they
>>> are supposed to.
>>
>> Damn, you're right.
>
> To be fair, it explodes as often as the if (isInputRange!T){static
> assert(!isInfinite!T);} does.
>

Right. It's just I did something similar to Philippe stuff previously and this somehow was an unpleasant surprise for me.

-- 
Dmitry Olshansky

On 7/23/12 7:10 AM, monarch_dodra wrote:
[snip]
> --------
> How do you feel about "assertive input validation" vs "conditional
> implementation"?
>
> Is this something you'd like to see more of in algorithm?

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.


Andrei