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 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