[Issue 16263] Error: template std.algorithm.iteration.permutations cannot deduce function from argument types !()(char[])
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[])
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[])
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[])
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[])
https://issues.dlang.org/show_bug.cgi?id=16263 Wyattchanged: 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[])
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[])
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[])
https://issues.dlang.org/show_bug.cgi?id=16263 Andrew Godfreychanged: 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[])
https://issues.dlang.org/show_bug.cgi?id=16263 Ketmar Darkchanged: 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. --