expectations 0.1.0
Paul Backus
snarwin at gmail.com
Mon Sep 3 06:49:41 UTC 2018
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky
(Abscissa) wrote:
> Note that the above has *nothing* to do with retrieving a
> value. Retrieving a value is merely used by the implementation
> as a trigger to lazily decide whether the caller wants `foo` or
> `tryFoo`. Going out of scope without making the choice could
> also be considered another trigger point. In fact, this
> "out-of-scope without being checked" could even be used as an
> additional trigger for even the non-void variety. After all:
> what if an error occurs, but the caller checks *neither* value
> nor hasValue?
The thing is, triggering on explicit access lets you handle
errors lazily, whereas triggering at the end of the scope forces
you to handle them eagerly.
Vladimir's `Success` type is, essentially, a way for a function
to send something back up the stack that its caller is forced to
acknowledge. Throwing an exception is *also* a way for a function
to send something back up the stack that its caller is forced to
acknowledge. The exact details are different, but when it comes
to overall control-flow semantics, they are basically equivalent.
By contrast, a function that returns an `Expected!T` does *not*
force its caller to acknowledge it. If an error occurs, and the
caller never checks value or hasValue...nothing happens. That's
what being lazy means: if you never open the box, it doesn't
matter whether the cat is alive or dead.
The problem, when it comes to `Expected!void`, is that there's no
good way to express what we *actually* care about--the function's
side effect--as a value. If we could write `Expected!(IO!Unit)`
like in Haskell, everything would be fine.
To me, the only acceptable choices are for `Expected!void` to
have the same lazy semantics as `Expected!T`, or for
`Expected!void` to be removed altogether. Having one
specialization be lazy and one be eager would be a nightmare for
anyone trying to use the library. For the reasons Vladimir
brought up, I'm leaning toward removal--without something like
Rust's `#[must_use]` attribute, it seems like `Expected!void` is
likely to do more harm than good.
More information about the Digitalmars-d-announce
mailing list