More fun with autodecoding

[Jonathan M Davis]

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