of "Conditional Implementation" vs "Assertive Input Validation"

[Jacob Carlborg]

On 2012-07-25 07:30, xenon325 wrote:

> How is it different from creating a template for every condition ? ;)

As long as you actually _do_ that, it might not be so much different.

> Honestly, I don't quite get what's the difference between current
> template constraints and ones you're proposing:
>
> // yours
> constraint InputRange (Range)
> {
>      alias ElementType!(Range.init) E;
>
>      @property bool empty ();
>      void popFront ();
>      @property E front ();
> }
>
> // std.range
> //
> https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#L549
>
> template isInputRange(R)
> {
>      enum bool isInputRange = is(typeof(
>      (inout int _dummy=0)
>      {
>          R r = void;       /*** how would you express this b.t.w. ? ***/
>          if (r.empty) {}
>          r.popFront();
>          auto h = r.front;
>      }));
> }
>
> on the call site it's as convenient and clear as yours.
> On the definition site, yes, syntax maybe is a tad worse,
> but it's not *that* bad to require introduction of a new
> language construct.

Well it depends on that syntax is used. It's clearer if this syntax 
would be possible:

void foo (InputRange range);

I think it's very little chance of a new language construct being added. 
It's more like I don't necessarily think the way the template 
constraints were implemented was the best way.

> Actually the only thing constraint writer needs to know is that
>      `is(typeof(<code>))`
> means "compiles". All the rest is perfectly clear.

And why is "(inout int _dummy=0)" there? I would guess that 
std.algorithm and other parts of Phobos is filled with strange things 
like this.

> I think I've addressed these points, let me know if
> I can explain it better.

Then the conclusion would at least be that std.algorithm could use some 
enhancement how these template constraints are written.

-- 
/Jacob Carlborg