On 02/02/16 21:24, Ali Çehreli wrote:
On 02/02/2016 07:21 AM, Shachar Shemesh wrote:
> it is a potential pitfall when implementing that I don't think is
> documented.
Good catch! Please either open a documentation bug for this or fork the
repo and fix it yourself. :) (Hopefully, there is an
On 2/2/16 10:21 AM, Shachar Shemesh wrote:
On 02/02/16 17:00, Steven Schveighoffer wrote:
Just put try around the opApply specific parts you want to monitor.
Don't guard the call to dg.
The call to dg is, obviously, part of a loop. That whole loop body is
inside a try/catch.
I don't see a
On 02/02/2016 07:21 AM, Shachar Shemesh wrote:
> it is a potential pitfall when implementing that I don't think is
> documented.
Good catch! Please either open a documentation bug for this or fork the
repo and fix it yourself. :) (Hopefully, there is an 'Improve this page'
link on that page.)
On 02/02/16 17:00, Steven Schveighoffer wrote:
Just put try around the opApply specific parts you want to monitor.
Don't guard the call to dg.
The call to dg is, obviously, part of a loop. That whole loop body is
inside a try/catch.
What I ended up doing, instead, was to put a flag, and the
On 2/2/16 4:44 AM, Shachar Shemesh wrote:
Please consider the following program:
import std.stdio;
struct A {
int opApply( scope int delegate(int) dg ) {
foreach(int i; 0 .. 50) {
try {
int res = dg(i);
if( res!=0 ) {
It seems this is a natural consequence of the lowering. As such,
I'm not surprised by the behaviour, of course under the
assumption I - as an end user - actually know that the given
opApply catches the exception. I guess there could be a
recommendation in opApply's specification that
