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



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



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






 Urgh, fixing this is going to be a breaking change, but not necessarily fix


bugs.

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






 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







 

 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