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.
Comment #1 by peter.alexander.au — 2014-03-19T16:23:52Z
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.
Comment #2 by monarchdodra — 2014-03-20T01:51:39Z
(In reply to comment #1)
> 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.
Comment #3 by bearophile_hugs — 2014-03-20T03:40:39Z
(In reply to comment #2)
> Yeah. I think the best thing to do at this point is to just let it be.
Really?
Comment #4 by monarchdodra — 2014-03-20T04:20:02Z
(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.
Comment #5 by n8sh.secondary — 2018-10-16T19:11:37Z
The code from OP currently prints "Tuple!(int, int, int)(1, 1, 1)" because of changes in https://github.com/dlang/phobos/pull/6307. This only applies to `zip` without an runtime StoppingPolicy argument, which implicitly uses StoppingPolicy.shortest, and only when the argument ranges support random access and/or slicing. (So it doesn't fix the problem with strings.)
Comment #6 by robert.schadek — 2024-12-01T16:20:35Z