expectations 0.1.0

[Paul Backus]

On Tuesday, 4 September 2018 at 22:08:48 UTC, Nick Sabalausky 
(Abscissa) wrote:
> I think you may be getting hung up on a certain particular 
> detail of Vladimir's exact "draft" implementation of Success, 
> whereas I'm focusing more on Success's more general point of 
> "Once the object is no longer around, guarantee the error 
> doesn't get implicitly squelched."
>
> You're right that, *in the draft implementation as-is*, it can 
> be awkward for the caller to then pass the Success along to 
> some other code (another function call, or something higher up 
> the stack). *Although*, still not impossible. So #3 still isn't 
> eliminated, it's simply made awkward...
>
> But reference counting would be enough to fix that. (Or a 
> compiler-supported custom datatype that's automatically 
> pass-by-moving, but that's of course not something D has).

Ok, I think I understand what you're proposing now--basically, 
something comparable to Rust's `#[must_use]` attribute. Thanks 
for taking the time to explain. I agree that that would be a nice 
feature for `Expected` to have.

The thing is, D already has a mechanism for signalling failures 
that can't be ignored: exceptions. So adding that functionality 
to `Expected`, while convenient, doesn't actually let you 
accomplish anything you couldn't already.

Now, if it were easy to implement, then sure, no problem. But 
it's not. Reference counting in particular is so problematic that 
Walter and Andrei have proposed *multiple* new language features 
(copy constructors, __mutable) to make it work cleanly. As things 
currently stand, making `Expected` reference-counted would mean 
at the very least giving up compatibility with `const` and 
`immutable`, which makes `Expected` a worse fit for strongly-pure 
functions (currently its *best* use-case).

It's a shame that D forces us to make this tradeoff, but given 
the options in front of me, I would rather have `Expected` shine 
in the area where it has a comparative advantage, even if that 
means making it less universally-applicable as an error-handling 
mechanism.