www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 17319] New: icmp - cannot use in sort with string array

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

          Issue ID: 17319
           Summary: icmp - cannot use in sort with string array arguments
                    - compilation fails
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Windows
            Status: NEW
          Severity: regression
          Priority: P1
         Component: phobos
          Assignee: nobody puremagic.com
          Reporter: furrymurray780 gmail.com

The following code will not compile:

import std.algorithm;
import std.range;
import std.uni;
/// Performs [["foo", "bar"], ["baz"]] -> ["baz", "foo bar"]
auto alphabetized(Range)(Range range)
{
     return range
          .map!(line => line.joiner(" "))
          .array
          .sort!((a, b) => icmp(a, b) < 0);
}

void main()
{
   auto a = alphabetized([["foo", "bar"], ["baz"]]);
}

Here's the error message I get:
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7082): Error:
 function 'std.algorithm.searching.skipOver!(Result,
 dstring).skipOver' is not nothrow
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7055): Error:
 nothrow function 'std.uni.fullCasedCmp!(Result).fullCasedCmp' may
 throw
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7136): Error:
 template instance std.uni.fullCasedCmp!(Result) error
 instantiating
 test.d(14):        instantiated from here: icmp!(Result, Result)
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1851):
   instantiated from here: __lambda3!(Result, Result) test.d(14):
 instantiated from here: sort!((a, b) =>
 icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
 test.d(19):        instantiated from here:
 alphabetized!(string[][])
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\sorting.d(1863):
 Error: static assert  "Invalid predicate passed to sort: __lambda3"
 test.d(14):        instantiated from here: sort!((a, b) =>
 icmp(a, b) < 0, cast(SwapStrategy)0, Result[])
 test.d(19):        instantiated from here:
 alphabetized!(string[][])
This is the explanation I got on dlang.learn (http://forum.dlang.org/post/mailman.1574.1491925305.31550.digitalmars-d-learn puremagic.com): Well, it's telling you that skipOver isn't nothrow, which only matters if it's being called from a nothrow function. It's then telling you that fullCasedCmp can't compile, because it's marked as nothrow, and it's calling a function that isn't nothrow (and thus could throw) - since it's calling skipOver. In turn, it's telling you that it can't instantiate fullCasedCmp (since it couldn't compile it, because it's nothrow but is calling a function that can throw). It's then telling you that fullCaseCmp was instantiated inside of icmp and that icmp was instantiated inside of a lambda that's at line 14 of test.d. At that point, you see a line in your code, so you know where in your code things went wrong, but it continues on, indicating that that means that sort won't compile and then that alphabetized won't compile. So, the problem here at the root of all of this is that when icmp is compiled with the ranges that you gave it, skipOver is inferred to _not_ be nothrow, whereas fullCasedCmp which is calling skipOver and in turn is called from icmp is marked as nothrow. So, the ranges that you're passing to icmp have functions which are called in skipOver which are not nothrow (probably front and popFront). This is a bug with fullCasedCmp (which is a private function calle by icmp). Someone decided to mark it as nothrow when it should _not_ have been marked as nothrow. It's also marked as trusted and pure - both of which are also wrong. The code is incorrectly assuming that the ranges that will be passed in have pure and nothrow functions and that they're not doing anything system which can't be assumed to be trusted. That will be true for some ranges but not others. In general, marking templated functions with attributes is a problem for exactly this reason. They must correctly apply to _all_ valid template arguments, or they shouldn't be there. So, this should be reported as a bug in icmp. --
Apr 11