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

2016-07-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #11 from Wyatt  ---
(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.

--


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

2016-07-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #9 from Ketmar Dark  ---
feel free to reopen it if you think it will be better this way. i still think
that it is not a bug, but i'm not D designer, thus may be wrong here.

or, maybe, it will be even better to create ER for improving the documentation,
and link to this bug from there. i'm all for fixing the things in one way or
another (preferably by killing autodecode ;-).

--


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

2016-07-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #8 from Wyatt  ---
(In reply to Ketmar Dark from comment #6)
> not a bug within the current state of things

I'm afraid I disagree: things not behaving as documented is always a bug.

> not "WONTFIX", as it *may* be fixed if devs will decide to remove
> autodecoding. so there is little choice left -- as bugreport *is* invalid
> (not a bug at all). sadly, we don't have "NOTABUG" reason to close it.

Usually, we call that "a normal open bug"?  Maybe depending on whichever
tracking bug is "kill autodecoding forever like we should have years ago"? 
Just because a bug can't be resolved as-is (or even plausibly in the near term)
doesn't mean it's invalid or not a bug.

Or maybe the title is wrong and it should really about fixing the docs to give
some indication that this is a thing people are going to hit or fixing the
compiler to give a useful error message instead of what, to anyone sane, is an
utterly mystifying complaint that water isn't wet.  Or both.  Or hell, make it
work as expected without the ugly hack!  Is that really not on the table?  How
has the community become so desensitised to this problem that bugs like this
just get closed outright?

I already thought autodecoding was rubbish from other angles, but this is
somehow the first time I've hit it like this.  I can easily see how people
would get discouraged from D in general if std.algorithm, supposedly one of the
shining stars of Phobos and D idioms in general, manages to break horribly when
you use an ordinary array of one of the base types.  Jesus, what a dumpster
fire.

Oh yes, it's also worth noting that default BZ search, which probably 99% of
people will use before filing one (if they even bother), doesn't turn up closed
bugs, which makes this nonsense effectively invisible. I only found it because
I searched the NG first and found the automated message on D.issues because I
didn't limit it to D.learn. 

In other words, the only reason I didn't report this precise issue again only
five days later was because of an *accident*.

--


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

2016-07-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #6 from Ketmar Dark  ---
this behavior is in the line with other autodecoding issues. while i don't
agree with it, it is not a bug within the current state of things, and it is
not "WONTFIX", as it *may* be fixed if devs will decide to remove autodecoding.
so there is little choice left -- as bugreport *is* invalid (not a bug at all).
sadly, we don't have "NOTABUG" reason to close it.

--


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

2016-07-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

Wyatt  changed:

   What|Removed |Added

 CC||wyatt@gmail.com

--- Comment #5 from Wyatt  ---
Hang on, in what world is this _invalid_?  The behaviour is clearly wrong.

I just ran into this exact problem and was tearing my hair out trying to figure
out why a bog-standard char[] is somehow failing to be random access and have
length.

--


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

2016-07-10 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #4 from Ketmar Dark  ---
oops. sorry, i must be on high today, and read your explanation completely
wrong. i'm really sorry.

--


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

2016-07-10 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

--- Comment #3 from Ketmar Dark  ---
while you are completely right here, OP didn't asked for correct unicode-aware
permutations (and dchars cannot support that too, by the way), he is just
telling that premutation of *chars* isn't working. so my `.byChar` solution
does actually solving OP's problem, and it does that perfectly. ;-)

--


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

2016-07-10 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

Andrew Godfrey  changed:

   What|Removed |Added

 CC||ag.dl...@gmail.com

--- Comment #2 from Andrew Godfrey  ---
(In reply to Ketmar Dark from comment #1)
> it is autodecoding again: std.utf.byChar will do the trick. note that it
> works perfectly with array of dchars, as those need not to be decoded.

That will not work "perfectly" in all languages. I don't speak a language where
it doesn't work, so can't give a good example. But it doesn't make sense to
permute dchars that don't represent whole 'characters'.

Anyway, I'm just cautioning against this apparent workaround.
If you need to permute characters, it sounds like you can use dchars, but you
should additionally restrict yourself to dchar values that represent whole
characters. (Or to languages where that's true for all the characters you'll
use).

--


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

2016-07-10 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16263

Ketmar Dark  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ket...@ketmar.no-ip.org
 Resolution|--- |INVALID

--- Comment #1 from Ketmar Dark  ---
it is autodecoding again: std.utf.byChar will do the trick. note that it works
perfectly with array of dchars, as those need not to be decoded.

--