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).

empty
bool empty()

Check if empty.

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.

opEquals
bool opEquals(typeof(this) rhs)
Undocumented in source.
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

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