On 8/25/21 10:22 AM, Paul Backus wrote:
On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001 wrote:
Would it be possible to extend `scope(exit)` and `scope(success)` to
trigger properly for functions returning `Expected!T` as defined in
the [expectations](https://code.dlang.org/packages/expectations) and
[expected](https://code.dlang.org/packages/expected) DUB libraries?
For example is it possible to make this work as expected:
```d
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.
I think it's possible to work with some mechanics that aren't
necessarily desirable. Something like:
```d
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:
```d
scope(success, r) if(r.isError) writeln("division failed");
else writeln("division succeeded");
```
That `scope(success)` kinda sucks though...
-Steve
