View mode: basic / threaded / horizontal-split · Log in · Help
July 23, 2012
of "Conditional Implementation" vs "Assertive Input Validation"
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?
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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.
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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.
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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).
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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.
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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
July 23, 2012
Re: of "Conditional Implementation" vs "Assertive Input Validation"
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home