Fix Issue 11913 - nothrow std.algorithm.zip

[monarchdodra]

Makes it an error to pass unequal-length ranges with requireSameLength. Allows using Zip in nothrow code.

[andralex]

this effectively changes "require" to "assume" - not sure if good

[andralex]

So are the changes enforce -> assert motivated by efficiency?

[monarchdodra]

this effectively changes "require" to "assume"

Technically "Require" implies no promises or assumption. "assume" and "enforce" do. "Require" is in a gray area (I think).

So are the changes enforce -> assert motivated by efficiency?

Both efficiency, and usability. The "problem" is that because the ending condition is a run-time one, these enforces over asserts are ruining it for everyone. Functions that otherwise would never throw anyways, are gratuitously marked as throwing.

This has a performance impact, and prevents them from being used in code that would otherwise be nothrow.

not sure if good

It's your call. For what it's worth, after this, I'll be working on making the stopping condition a compile time parameter (I can do this without breakage), so the issue should also spontaneously resolve, thanks to finer grained (and compile time) end conditions.

Doing this here now means users will benefit from in ASAP: the "new" Zip I'm working on will be opt-in until the old one is fully deprecated and removed. Only then can the new compile time Zip replace the old run-time one by default. So it could be a while.

---

Regardless, I think front/popFront can be made nothrow regardless: That's standard out of bounds checking, not input validation.

[monarchdodra]

EDIT: Of course, there's the fact that the checks are not removed in release, making the Zip much slower than it should be, even for requireSameLength.

[JakobOvrum]

This is a breaking change. I'd rather we just fix it in the template-parameter version.

[monarchdodra]

This is a breaking change. I'd rather we just fix it in the template-parameter version.

Yeah, probably the best idea. I'll just close this.