[Issue 16263] Error: template std.algorithm.iteration.permutations cannot deduce function from argument types !()(char[])

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #11 from Wyatt <wyatt.epp at gmail.com> ---
(In reply to ag0aep6g from comment #10)
> (In reply to Wyatt from comment #8)
> > I'm afraid I disagree: things not behaving as documented is always a bug.
> 
> As far as I see, everything works as documented. Please point out where it
> doesn't.

I've spent ten minutes trying to figure out if you're serious or if this is
just a joke that falls flat.  I'm pretty sure you understand why this is bad,
but on the off chance you're really arguing that everything is fine, I'll
clarify.

So, according to the documentation, std.algorithm.iteration.permutations:
"Lazily computes all permutations of r using Heap's algorithm." 

It returns a forward range of a std.range.indexed (which is cross-referenced
here) and there's an example (conscripted unit test).

Okay, that's pretty good for Phobos!  Maybe it'd be good to have a bit more
explanation of what permutation means for the initiate, and the example should
also include something related to actually using the result that you get back,
but it covers the essentials.  That at least ought to be enough for anyone who
isn't writing their own range types.  In fact, the constraints are (rightly)
greyed out because they're largely irrelevant unless you're writing your own
range types.

And yet ordinary arrays of one of the most common types do not work without an
ugly hack that requires another import.  Unlike every other basic type.*

Instead of working, they fail with a very misleading message that makes zero
sense unless you've apparently read-in-depth the documentation for those
constraints.  Which aren't actually linked here.  This is also unlike every
other basic type.*

*(except for wchar, which no one loves).

Oh right, and that other module's docs also don't mention the hack OR advise
using dchar[] instead, so good luck figuring that out on your own. (PS: Don't
forget, you'll have to figure out what the other module even is and find its
docs on your own because it's not linked here.)

So sure, you _can_ argue that it's "documented", but that's like saying the
dumpster fire's not a problem because you're upwind and have a rebreather.

N.B. This is the sort of thing that drives people away.  You know those
complaints about how the docs suck and nothing works?  This is a great example
of that.

So now that we've clarified the badness, here's some actionable bits (I should
probably take ketmar's suggestion and file a broader ER about this but I'm
short on time right now):
- Add warnings (with text _and_ links) that using char[] is going to screw
users.
- Add an example that shows permutations used on char[] and dchar[].
- Have the compiler explain the actual problem.  Ugly?  Maybe.  Special casing
is bad?  Sure.  But the current error is way out of left field.
- Make it actually work like it should. Especially if the input is known at
compile time, this shouldn't be a problem.
- Obligatory "kill autodecoding" bullet point.

--