Expected

Union (sum) type of either an expected (most probable) value of type T or an unexpected value of type E (being an instance of type Unexpected!E).

E is typically an error code (for instance C/C++'s' errno int) or a subclass of Exception (which is the default).

Constructors

this
this(T expectedValue)

Construct from expected value expectedValue.

this
this(Unexpected!E unexpectedValue)

Construct from unexpected value unexpectedValue.

Members

Functions

apply
Expected!(typeof(unaryFun!fun(T.init)), E) apply()

If this is an expected value (of type T) apply fun on it and return result, otherwise return current unexpected value (of type E).

hasExpectedValue
bool hasExpectedValue()

Is true iff this has a expectedValue of type T.

opAssign
void opAssign(T expectedValue)

Assign from expected value expectedValue.

opAssign
void opAssign(E unexpectedValue)

Assign from unexpected value unexpectedValue.

popFront
void popFront()

Pop (clear) current value.

valueOr
CommonType!(T, typeof(elseWorkFun())) valueOr()

Get current value if any or call function elseWorkFun with compatible return value.

Properties

empty
bool empty [@property getter]

Check if empty.

front
inout(T) front [@property getter]

Get current value.

See Also

https://www.youtube.com/watch?v=nVzgkepAg5Y

https://github.com/dlang/phobos/pull/6665

https://code.dlang.org/packages/expectations

https://doc.rust-lang.org/std/result/

https://github.com/tchaloupka/expected

TODO https://dlang.org/phobos/std_typecons.html#.apply

TODO I'm not convinced about the naming - Expected: instead call it something that tells us that it can be either expected or unexpected? - Unexpected: if so why shouldn't we have a similar value wrapper Expected?

TODO we could get around the Unexpected wrapper logic by instead expressing construction in static constructor functions, say,: - static typeof(this) fromExpectedValue(T expectedValue) - static typeof(this) fromUnexpectedValue(E unexpectedValue)

TODO swap

TODO which functions should be nothrow?

TODO later on: remove _ok when _expectedValue and _unexpectedValue can store this state "collectively" for instance when both are pointers or classes (use trait isAddress)

TODO ok to default E to Exception?

Meta