Re: expectations 0.1.0

[Paul Backus via Digitalmars-d-announce]

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.