• Dukc (12/12) Jul 19 2017 I decided to try adding an overload to Zip which remembers it's
• Meta (4/17) Jul 19 2017 Nowadays that would probably be made an assertion and maybe put

Dukc <ajieskola gmail.com> writes:

I decided to try adding an overload to Zip which remembers it's 
stopping policy at compile time. But I encountered another 
strange design.

When stopping policy is set to requiring a same length, and it is 
not so, it throws a regular exception. I think this is 
inconsistent with rest of the language, because according to TDPL 
exceptions are meant to intercept normal things the programmer 
has no control over, Mainly I/O failures as I understand it.

But here, if someone zips ranges of different length, it is 
clearly a programmers error, not corrupted input. So shouldn't it 
assert() the length (and be nothrow) instead?

And what would you think if I redesigned it so while I'm on it?

Meta <jared771 gmail.com> writes:

On Wednesday, 19 July 2017 at 12:59:46 UTC, Dukc wrote:
 I decided to try adding an overload to Zip which remembers it's 
 stopping policy at compile time. But I encountered another 
 strange design.

 When stopping policy is set to requiring a same length, and it 
 is not so, it throws a regular exception. I think this is 
 inconsistent with rest of the language, because according to 
 TDPL exceptions are meant to intercept normal things the 
 programmer has no control over, Mainly I/O failures as I 
 understand it.

 But here, if someone zips ranges of different length, it is 
 clearly a programmers error, not corrupted input. So shouldn't 
 it assert() the length (and be nothrow) instead?

 And what would you think if I redesigned it so while I'm on it?

Nowadays that would probably be made an assertion and maybe put 
in an in-contract, but zip is quite an old function so it doesn't 
follow the more modern D conventions.