of "Conditional Implementation" vs "Assertive Input Validation"

[xenon325]

On Wednesday, 25 July 2012 at 07:23:51 UTC, Jacob Carlborg wrote:
> On 2012-07-25 07:30, xenon325 wrote:
>
>>> For this to be useful you really need to create a template 
>>> for every condition
[snip]
>>> With my approach the constraint will have a name which should 
>>> result in a lot better error messages.
>>
>> 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.

But you would have to create a constraint for every condition as 
well!
And if someone implements Don's idea, error messages would be as 
good.


>> Honestly, I don't quite get what's the difference between 
>> current
>> template constraints and ones you're proposing:
[snip]
>> 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);

1. How would you signify `foo` is generic ?
    For complier it's probably possible - by type of `InputRange`,
      but that will be one more special case
    What about user ?

2. How would you put 2 constraints on `range` ?

3. Also you forgot to address:

>> template isInputRange(R)
>> {
>>      enum bool isInputRange = is(typeof(
>>      (inout int _dummy=0)
>>      {
>>          R r = void;       /*** how would you express this 
>> b.t.w. ? ***/

    range.d comment on this line is "can define a range object".


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

Sorry, but I still fail to see how you way is (significantly) 
better.


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

Yeah :) My thoughts (have really little D experience):
1. why is it lambda
2. why does it have argument
3. why is arg `inout`
4. why is *dummy* arg initialized

I would think it's some kind of temporary compiler workaround.
But if it's something smart, it could definitely use
better syntax, no objections here (__traits( compiles, ..) ?).


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

Agree, `(inout int _dummy=0)` is confusing. There well may be 
other (as confusing) examples but probably there are easy ways to 
fix them.
Maybe you should create enhancement request or discuss it with 
community ?


Wait! We were talking about how to make compiler error messages 
better.