expectations 0.1.0

[Nick Sabalausky (Abscissa)]

On 09/02/2018 11:23 PM, Paul Backus wrote:
> 
> This is a really clever technique. As you said, hard to say whether it's 
> worth it compared to just throwing an exception normally, but still, 
> really clever.

IMO, it's worth it. First of all, it decreases the asymmetry between 
`Expected!void` and other `Expected!T`. But more than that, there's one 
of the core benefits of of expected:

What's awesome about expected is that by providing only one function, 
the caller can decide whether they want a `foo()` that throws, or a 
`tryFoo()` that lets them manually handle the case where it doesn't work 
(and is potentially nothrow).

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?

There's only one possible downside I see:

What if the caller *intentionally* wants to ignore the error condition? 
Yes, that's generally bad practice, and signifies maybe it shouldn't be 
an exception in the first place. But consider Scriptlike: It has 
functions like `tryMkdir` and `tryRmdir` with the deliberate purpose 
letting people say "Unlike Phobos's mkdir/rmdir, I don't care whether 
the directory already exists or not, just MAKE SURE it exists (or 
doesn't) and don't bother me with the details!"

I suppose for cases like those, it's perfectly worth leaving it up to 
expectation's user to design, create and document a "Don't worry about 
the failure" variant, should they so choose. Probably safer that way, 
anyway.