www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12404] New: Zip.back is wrong

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12404

           Summary: Zip.back is wrong
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: monarchdodra gmail.com


--- Comment #0 from monarchdodra gmail.com 2014-03-18 07:31:34 PDT ---
Because it processes the back of each range, rather than an index. EG:

//----
import std.range, std.stdio;

void main()
{
    auto a = [1];
    auto b = [1, 2];
    auto c = [1, 2, 3];
    zip(a, b, c).back.writeln();
}
//----

This writes "Tuple!(int, int, int)(1, 2, 3)".

For "shortest", it should print "1, 1, 1".
For "longest", it should print "0, 0, 3".

For "same length", it's an error.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 18 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12404


Peter Alexander <peter.alexander.au gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.alexander.au gmail.co
                   |                            |m


--- Comment #1 from Peter Alexander <peter.alexander.au gmail.com> 2014-03-19
16:23:52 PDT ---
Urgh, fixing this is going to be a breaking change, but not necessarily fix
bugs.

assert(zip("abc", "123").back == tuple('c', '3'));

That's correct, and works, but your fix requires length and indexing, which
narrow strings don't have.

If indexing and length aren't available, back should assert if the stopping
policy is not requireSameLength.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 19 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12404



--- Comment #2 from monarchdodra gmail.com 2014-03-20 01:51:39 PDT ---
(In reply to comment #1)
 Urgh, fixing this is going to be a breaking change, but not necessarily fix

Yeah. I think the best thing to do at this point is to just let it be. I wasn't planning to do anything about it. Still, wrong is wrong, so it justified filing it. Just one more reason to bump the static Zip priority up the stack. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12404


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #3 from bearophile_hugs eml.cc 2014-03-20 03:40:39 PDT ---
(In reply to comment #2)

 Yeah. I think the best thing to do at this point is to just let it be.

Really? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12404



--- Comment #4 from monarchdodra gmail.com 2014-03-20 04:20:02 PDT ---
(In reply to comment #3)
 (In reply to comment #2)
 
 Yeah. I think the best thing to do at this point is to just let it be.

Really?

As Peter said, fixing it would break this: `zip("abc", "123").back` The fix would be silent breakage, because instead of static asserting, we'd be run-time asserting. And even then, if the user wrote: `zip(StoppingPolicy.requireSameLength, "abc", "123").back` We'd add *yet* more run-time overhead to something that is meant to be fast to begin with. And it would *still* not be completely correct, since it isn't an *Error* to give it ranges with different lengths... At best, we could Band-Aid it with a message: //---- "back/popBack will only function correctly on the `requireSameLength` stopping scheme, and provided the ranges actually do have the same length." //---- So I'm all ears, but I don't see how we can do much about it at this point. //--------- Related, opIndex/opSlice has the same issue for "longuest": import std.range, std.stdio; void main() { auto a = [1]; auto b = [1, 2]; auto c = [1, 2, 3]; zip(StoppingPolicy.longest, a, b, c)[2]; } That said, *that's* fixable, but there'd still be a definite run-time overhead. //-------- My stance is I don't want to waste any more time/effort on something that can't be fixed. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2014