https://d.puremagic.com/issues/show_bug.cgi?id=12404
--- Comment #4 from monarchdo...@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: -------