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