extend optional with error data
Use a union for the success and error data. Make access to the error variant explicit. The error data type can have a default template argument for compatibility with existing code and readability.
The union has the additional benefit that no default constructor is needed for the success data type. We have some place in the user-mode runtime library where we are interested in the data specifically just on errors. For example, when mapping a frame into an adress space fails, we want to know where and why. At the moment this triggers nasty debugging messages.
We should rename mythos::Error to mythos::Status because it is used for all sorts of status codes, not just errors. mythos::optional should use a separate flag bit to differentiate between the expected result and error result instead of assuming that any status code other than SUCCESS represents an error.
The implementation can be inspired by the std::expected proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf and add the convenience methods from https://github.com/TartanLlama/expected. However, I think that we can stay with the mythos::Status as general result code. Examples:
- mythos::optional<T> contains a status code and a value of T in case of success
- mythos::optional<T,E> contains a status code, a value of T in case of success but a value of E in cause of an error.
Implementation can use a union { T good; E bad; }; internally. Use E=void as default template argument. Think about how we can avoid to do special case template instantiations for all combinations of T and E (non-)void.
A good discussion of the std::extected proposal: https://www.youtube.com/watch?v=PH4WBuE1BHI