Comment #0 by bearophile_hugs — 2013-10-21T17:42:45Z
import std.range: zip;
void main() nothrow {
foreach (p; zip([1], [2])) {}
}
dmd 2.064beta2 gives:
test.d(3): Error: 'std.range.Zip!(int[], int[]).Zip.empty' is not nothrow
test.d(3): Error: 'std.range.Zip!(int[], int[]).Zip.popFront' is not nothrow
test.d(2): Error: function 'D main' is nothrow yet may throw
Comment #1 by andrej.mitrovich — 2014-04-25T10:05:29Z
This is a bit impossible to fix.
We could change all exceptions to be RangeError, which would make everything nothrow. However that would break @safe, because safe functions cannot catch Errors. It would also break any code which happened to handle exceptions being thrown out of a zip() call.
So I'm not sure what to do with this.
Comment #2 by bearophile_hugs — 2014-04-25T10:45:53Z
(In reply to Andrej Mitrovic from comment #1)
> This is a bit impossible to fix.
This is a rather important issue, because zip is used often in functional-style code. So lot of that code can't be nothrow because of zip.
Perhaps this issue is a duplicated, because elsewhere I've seen more discussion about this problem.
I think this problem can be fixed in one cast that is important and common. I remember the zip that needs to throw is just the one the requires equal length ranges as input. So the most common zip could be nothrow. To do this you have to specify what kind of zip behavour you want with a compile-time argument, to allow the static specialization. This means changing zip API a little. Perhaps such change can be done in a gentle way, allowing both APIs for some time.
Comment #3 by andrej.mitrovich — 2014-04-25T12:55:07Z
Comment #5 by andrej.mitrovich — 2014-04-25T14:06:59Z
(In reply to bearophile_hugs from comment #4)
> (In reply to Andrej Mitrovic from comment #3)
> > https://github.com/D-Programming-Language/phobos/pull/2125
>
> I think you have not solved the problem much, you just have renamed errors
> the new exceptions.
There was a misunderstanding from my part on Errors. Anyway it's not an easy problem to solve after all.
Comment #6 by bearophile_hugs — 2014-04-25T14:09:15Z
(In reply to Andrej Mitrovic from comment #5)
> Anyway it's not an easy problem to solve after all.
What do you think about the idea of Comment #2? :-)
Comment #7 by monarchdodra — 2014-04-25T15:10:51Z
*** Issue 11913 has been marked as a duplicate of this issue. ***
Comment #8 by n8sh.secondary — 2018-10-16T19:18:08Z