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?
