On Saturday, September 15, 2018 9:31:00 AM MDT Steven Schveighoffer via Digitalmars-d wrote:
> On 9/13/18 3:53 PM, H. S. Teoh wrote:
> > On Thu, Sep 13, 2018 at 06:32:54PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> >> On 09/11/2018 09:06 AM, Steven Schveighoffer wrote:
> >>> Then I found the true culprit was isForwardRange!R. This led me to requestion my sanity, and finally realized I forgot the empty function.
> >>
> >> This is one reason template-based interfaces like ranges should be required to declare themselves as deliberately implementing said interface. Sure, we can tell people they should always `static assert(isForwardRage!MyType)`, but that's coding by convention and clearly isn't always going to happen.
>
> No, please don't. I've used C# and Swift, and this sucks compared to duck typing.
>
> > Yeah, I find myself writing `static assert(isInputRange!MyType)` all the time these days, because you just never can be too sure you didn't screw up and cause things to mysteriously fail, even though they shouldn't.
> >
> > Although I used to be a supporter of free-form sig constraints (and still am to some extent) and a hater of Concepts like in C++, more and more I'm beginning to realize the wisdom of Concepts rather than free-for-all ducktyping.  It's one of those things that work well in small programs and fast, one-shot projects, but don't generalize so well as you scale up to larger and larger projects.
>
> The problem I had was that it wasn't clear to me which constraint was failing. My bias brought me to "it must be autodecoding again!". But objectively, I should have examined all the constraints to see what was wrong. All C++ concepts seem to do (haven't used them) is help identify easier which requirements are failing.
>
> We can fix all these problems by simply identifying the constraint clauses that fail. By color coding the error message identifying which ones are true and which are false, we can pinpoint the error without changing the language.
>
> Once you fix the issue, it doesn't error any more, so the idea of duck typing and constraints is sound, it's just difficult to diagnose.

The other two things that come to mind are that

1. Design by Introspection is pretty much the opposite of Concepts, and while I'm not convinced that DbI is a great idea in general, there clearly are cases where it makes a lot of sense (e.g. allocators), and it's something that Andrei wants to push (whereas unless something has changed, he's very much against Concepts). Adding any sort of Concepts feature to D would be very much at odds with DbI. And honestly, in general, I don't think that it's at all necessary. As you point out, it's really the error reporting that's the problem. Aside from that, template constraints tend to work quite well.

2. Improving the error reporting for constraints improves templates in general and not just those that use traits like isInputRange. While we do create traits for the really common stuff, there's plenty of code that is going to do stuff like is(typeof(...)), because it's a one-off thing, and it would be overkill to create a trait for it. So, improving the error reporting would ultimately be very useful in general, whereas trying to do something with Concepts would only help with part of the problem.

And of course, there's always going with Atila's approach of providing a separate template that goes with the trait and tells you which piece fails for a particular template argument (though that obviously doesn't scale).

Overall though, I don't think that there's really any disagreement that it would be very desirable to get the compiler to provide better information about which parts of a template constraint are true and which are false. The problem is really that someone needs to come up with a scheme to do so that will work reasonably well and then implement it, and no on has done that yet.

- Jonathan M Davis

On 09/15/2018 04:29 PM, Jonathan M Davis wrote:
> 
> Adding any sort of Concepts feature to D
> would be very much at odds with DbI.

I'm not very familiar with C++'s attempted approaches to concepts, so maybe we're thinking of two different things by "concepts", but I don't see why it would be at odds with DbI. If anything, they would seem to compliment each other well, each one filling in where the other hits its limit. Even just a simple example:

void foo(ForwardRange r1, InputRange r2)
if(hasLength!r1)
{...}

Andrei is right that a no-DbI version of that would suck: Hierarchies are no good for a series of orthogonal options. But at the same time, the equivalent current-D code would comparatively be a mess, too.

Although...and maybe I'm just typing out of my &%@ here, maybe some kind of templated concept:

void foo(ForwardRange!WithLength r1, InputRange r2)
{...}


> Overall though, I don't think that there's really any disagreement that it
> would be very desirable to get the compiler to provide better information
> about which parts of a template constraint are true and which are false. The
> problem is really that someone needs to come up with a scheme to do so that
> will work reasonably well and then implement it, and no on has done that
> yet.

Agreed, but let's be realistic, this *is* D: How many years has it been since assertPred was rejected in favor of the improved-assert-messages vaporware? It's hard to have much faith in such a thing happening here either. (Not that I'm under any illusion that concept-like stuff would be any more likely.)

Though, I'd be glad to be proven wrong either way.

-- Danny Downer