Would it be possible to extend scope(exit) and scope(success) to trigger properly for functions returning Expected!T as defined in the expectations and expected DUB libraries?

For example is it possible to make this work as expected:

Expected!int divide(int a, int b) nothrow
{
    scope (failure) writeln("division failed");
    scope (success) writeln("division succeeded");

    if (b == 0) return err!int("division by zero");
    return ok(a / b);
}

On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001 wrote:

Expected!int divide(int a, int b) nothrow
{
    scope (failure) writeln("division failed");
    scope (success) writeln("division succeeded");

    if (b == 0) return err!int("division by zero");
    return ok(a / b);
}

Probably the only principled way to make this work would be to define some kind of "concept"/structural interface that's recognized by the compiler to mean "this is an error-handling type", in the same way that the compiler recognizes empty/front/popFront to mean "this is an iterable type".

Even then, it would require some pretty invasive language changes (and some pretty gnarly code in the compiler), but it's at least theoretically possible.

On Wednesday, 25 August 2021 at 14:22:26 UTC, Paul Backus wrote:

do you think this would be worth a DIP that could get in? Or should usage in these packages grow first?

On 8/25/21 10:22 AM, Paul Backus wrote:

Expected!int divide(int a, int b) nothrow
{
    scope (failure) writeln("division failed");
    scope (success) writeln("division succeeded");

    if (b == 0) return err!int("division by zero");
    return ok(a / b);
}

I think it's possible to work with some mechanics that aren't necessarily desirable. Something like:

ErrorHandler error = registerErrorHandler;
error.onFailure({writeln("division failed");});
error.onSuccess({writeln("division succeeded");});

...

On returning err, the registration would trigger a flag saying an error is occurring, and call the right callback when ErrorHandler is destructing. The cleanup of the return value would clean up the error condition. It would be messy and likely brittle.

I've also advocated in the past that it would be nice to have access to the things that are causing the success, failure, etc.

Like scope(failure, exception) writeln("Exception being thrown is ", exception)

Could be extended to:

scope(success, r) if(r.isError) writeln("division failed");
                  else          writeln("division succeeded");

That scope(success) kinda sucks though...

-Steve

On 8/25/21 10:42 AM, Steven Schveighoffer wrote:

One has to weigh how much this is preferred to actual exception handling...

If something like DIP1008 could become usable, it might alleviate even the need for such things.

-Steve

On Wednesday, 25 August 2021 at 14:42:07 UTC, Steven Schveighoffer wrote:

ErrorHandler error = registerErrorHandler;
error.onFailure({writeln("division failed");});
error.onSuccess({writeln("division succeeded");});

...

Hm I'm not quite seeing how the error handler is related to an "Expected type interface" that the compiler could expect.

Currently with exceptions the scope things are implemented using try-catch-finally, this would be even simpler:

scope(exit) exit();
scope(success) success();
scope(failure) failure();

return something();

lowers to

auto ret = something();
if (ret.isError) failure();
if (!ret.isError) success();
exit();
return ret;

for all return statements.

I might be missing some obvious drawbacks here but I think this sounds reasonable and comparable with the try-catch-finally lowering.

As Paul Backus suggested the compiler could check if the return type has for example is(typeof(return.isError) : bool) and maybe also if the function is nothrow.

On Wednesday, 25 August 2021 at 14:52:34 UTC, Steven Schveighoffer wrote:

DIP1008 is a nice step forward, but I think sometimes explicit error handling is nicer, and especially with C interop and concurrency (like vibe.d tasks) nothrow is pretty good to have.

On Wednesday, 25 August 2021 at 14:42:07 UTC, Steven Schveighoffer wrote:

ErrorHandler error = registerErrorHandler;
error.onFailure({writeln("division failed");});
error.onSuccess({writeln("division succeeded");});

...

This is kind of like what Common Lisp has with its condition system. One downside of this approach in D is that it would not work well with static analysis features like @safe, nothrow, etc., since the handlers are not known until runtime. But it does offer a lot more flexibility than traditional exceptions.

On 8/25/21 10:58 AM, WebFreak001 wrote:

This would be without compiler changes.

scope(exit) exit();
scope(success) success();
scope(failure) failure();

return something();

auto ret = something();
if (ret.isError) failure();
if (!ret.isError) success();
exit();
return ret;

It does sound pretty reasonable. But overloading these existing features might make things confusing.

Another approach is to let the compiler deal with the error handling and not muddy your return type. Swift does something similar, where it rewrites the throw/catch into a standard return and doesn't do actual thrown exceptions. There are some caveats, but if we could fit this kind of error handling into mostly-similar syntax (i.e. the same ease of exceptions without the actual problems that exceptions and stack unwinding bring), it might make things much easier to transition.

-Steve

On Wednesday, 25 August 2021 at 15:30:57 UTC, Steven Schveighoffer wrote:

I like the Swift error handling, so I think this would be a great idea for nothrow code with error handling too.