digitalmars.D.bugs - [Issue 9071] New: sort function won't compile but Range fits describtion
- d-bugmail puremagic.com (23/23) Nov 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (21/21) Nov 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (20/20) Nov 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (17/35) Nov 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (8/8) Nov 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (39/39) Nov 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (14/28) Dec 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (7/7) Dec 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (15/18) Dec 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9071
- d-bugmail puremagic.com (12/12) Jan 02 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9071
http://d.puremagic.com/issues/show_bug.cgi?id=9071 Summary: sort function won't compile but Range fits describtion Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: rburners gmail.com --- The function sortImpl implies that the type returned by the slice operator of the passed range is of the same type. This must not be true. If it is not sortImpl will not instantiate recursively because of a type mismatch. This is a problem for custom container. (Currently I have this problem) To fix this. It should be checked whether or not the returned type of the opSlice funtion is of the same type as the original range. static assert(is(ReturnType!(Range.opSlice) == Range)); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 24 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra gmail.com This is actually a problem with "hasSlicing": It is currently being tightened so that the result of a slice operation *must* be convertible back to the original type. If this is not the case, then the range will not be considered sliceable. Once this is deployed, you will (should) be forwarded to the "correct" overload of sortImpl: The one that doesn't use slicing. Still, could you please provide the code example that fails? This will help us figure out which of the following is the culprit: * The range? * The definition of hasSlicing? * The implementation of sort? And correctly address the issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 --- where do you want the examples. it is pretty long 270 lines. The problem is a combination of the way opSlice doesn't require a specific return type and. the recursive nature of sortImpl and that sortImpl assigns slices. algorithm.d:7306 auto right = r[lessI + 1..r.length]; // here r is still of type Range // right is the return type of opSlice auto left = r[0..min(lessI, greaterI + 1)]; // same goes for left if (right.length > left.length) { swap(left, right); } .sortImpl!(less, ss, Range)(right); // here sortImpl calls itself where right is not of type Range r = left; // this assignment will fail because the assign operator of Range is not required to accept the return type of opSlice -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody puremagic.com |monarchdodra gmail.com Severity|enhancement |normalwhere do you want the examples. it is pretty long 270 lines.You can post it in dpaste: http://dpaste.dzfl.pl/new An added bonus is that it should show us the exact same compile error you are getting.The problem is a combination of the way opSlice doesn't require a specific return type and. the recursive nature of sortImpl and that sortImpl assigns slices. algorithm.d:7306 auto right = r[lessI + 1..r.length]; // here r is still of type Range // right is the return type of opSlice auto left = r[0..min(lessI, greaterI + 1)]; // same goes for left if (right.length > left.length) { swap(left, right); } .sortImpl!(less, ss, Range)(right); // here sortImpl calls itself where right is not of type Range r = left; // this assignment will fail because the assign operator of Range is not required to accept the return type of opSliceI see. In that case, there is a bit of both issues. Please post your code, I'll take care of this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 --- http://dpaste.dzfl.pl/163a9600 prints the exact same error thanks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 OK, what you showed me was that indeed, "deque" is not "sliceable" according to the new definition. It does also show that there are some issues in sort's implementation that need to be looked into. However (next section relevant), note that it is perfectly possible to sort your container via a slice of that container: http://dpaste.dzfl.pl/e601b75a I just added "opSlice();", and changed the call to: std.algorithm.sort!("a < b")(de[]); -------- On a side note, regarding your dequeue implementation: You are mixing the notion of container, and range. A container holds stuff. A range gives you an interface to access that stuff. The difference becomes apparent once you start poping stuff. A range is expected to merelly "walk forward", whereas your container will actually discard and destroy its elements: Not the expected behavior. This is especially true in your "save" implementation: Save is just supposed to duplicate the range (the view) itself, but not the elements. In particular, this should always hold (provided non-transisent assignable): Range r = something; auto rr = r.save; r.front = someValue; assert(rr.front == someValue); In your case, your implementation of "save" is what "dup" should be. Your save should probably be implemented as simply "return this"; Do you have a C++ background? It's kind of the same in the sense that you can't sort a container directly, but a pair of that container's iterator. Unless you have a Java background? Anyways, the "standard" fix is usually to just rename your "popFront" functions into "removeFront". -------- Last but not least (since I'm reviewing your implementation), it is usually considered an *error* to access past an empty range/iterator, or to access past the valid bounds of a container. It is usually recommended in that case to error-out (assert) instead. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071This is actually a problem with "hasSlicing": It is currently being tightened so that the result of a slice operation *must* be convertible back to the original type. If this is not the case, then the range will not be considered sliceable. Once this is deployed, you will (should) be forwarded to the "correct" overload of sortImpl: The one that doesn't use slicing. Still, could you please provide the code example that fails? This will help us figure out which of the following is the culprit: * The range? * The definition of hasSlicing? * The implementation of sort? And correctly address the issue.OK: According to the new tests, the new definition of has slicing partially fixes the problem. However, there are currently no restraints for "sort", so the compilation error is: /usr/local/include/dmd2git/std/algorithm.d(7357): Error: template instance SortedRange!(Deque, "a < b") SortedRange!(Deque, "a < b") does not match template declaration SortedRange(Range, alias pred = "a < b") if (isRandomAccessRange!(Range) && hasLength!(Range)) I'll add a new restraint then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 --- That sounds very good. Thank you! p.s. Can you point me to the new slicing definition? Anyway thanks again -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071That sounds very good. Thank you! p.s. Can you point me to the new slicing definition? Anyway thanks againThe new slicing definition is only documented in code right now, but you'll find it here: https://github.com/D-Programming-Language/phobos/blob/2bbb33df2fa9f87ae73de6924031e1a854756ea1/std/range.d#L1236 To sum it up in a jiffy, the type returned by slice must be an exact type match of the original.* There are also special conditions in regards to infinite ranges and opDollar, but I'll let you read about those. *Not yet fully enforced due to a bug, but documented that way anyways, and will end up that way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 28 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9071 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE Closing as duplicate of 8368, which is currently being fixed. *** This issue has been marked as a duplicate of issue 8368 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 02 2013