expectations 0.1.0

[aliak]

On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote:
> 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.

I'm leaning on agreeing with removal of Expected!void as well

When we get opPostMove then maybe Expected!void can throw on a 
move or a copy if the result was a failure. This would also not 
allow the error to be ignored as it'd throw.

Or... can it throw in ~this() if it was not checked?