I probably should have thought of asking this earlier, but it occurs to
me now that my own mental model of how an "outcome"-ish type should act
is probably not suited to variant storage at all.
So just out of curiosity I thought I'd ask whether people prefer this
sort of interface:
template<typename T>
class outcome
{
public:
bool has_value() const { return m_storage.has<T>(); }
T& value() { return m_storage.get<T>(); }
bool has_error() const { return m_storage.has(); }
error_code& error() { return m_storage.get(); }
bool has_exception() const { return m_storage.has(); }
exception_ptr& exception() { return m_storage.get(); }
void set(none_t) { m_storage = none; }
void set(const T& val) { m_storage = val; }
void set(error_code err) { m_storage = err; }
void set(exception_ptr ep) { m_storage = ep; }
private:
variant m_storage;
};
Or this sort of interface:
template<typename T>
class outcome
{
public:
bool has_value() const { return !!m_value; }
T& value() { ensure(); return m_value.value(); }
//bool has_error() const { return !!m_error; }
const error_code& error() const { return m_error; }
//bool has_exception() const { return !!m_exception; }
const exception_ptr& exception() const { return m_exception; }
void ensure() const
{
if (m_exception) { rethrow_exception(m_exception); }
if (m_error) { throw system_error(m_error); }
}
void set(none_t)
{
m_value = none;
m_error = error_code();
m_exception = nullptr;
}
void set(const T& val)
{
m_value = val;
m_error = error_code();
m_exception = nullptr;
}
void set(error_code err)
{
m_value = none;
m_error = err;
m_exception = nullptr;
}
void set(exception_ptr ep)
{
m_value = none;
m_error = ep ? error_code(errc::has_exception) : error_code();
m_exception = ep;
}
private:
optional<T> m_value;
error_code m_error;
exception_ptr m_exception;
};
(Don't get too hung up on the specifics. This is a sketch, not a real
implementation. I've obviously omitted things that a real
implementation would need such as more const methods and move support,
and construction and assignment rather than using set methods. The
focus is on variant vs. non-variant.)
Anyway, the point is that this could actually transport multiple things;
in particular as above both an error_code and an exception_ptr; perhaps
set(error_code) could construct an exception as well, although I've
explained elsewhere why I don't like that option.
Perhaps this could even be exposed even more so that user code could
explicitly provide both a value and an error -- think "here's a value,
but it was truncated" or "here's the 5 values you asked for, but there's
more", both fairly common in system APIs. Or for things like ambiguous
matches where you still return the most likely candidate. Or dictionary
insertion (duplicate key, but here's the value that's already there).
Or many more such examples. (Though obviously in this case value()
couldn't call ensure(). But that should make some people happy.)
Also note has_error() and has_exception() don't even need to be provided
in this version since you can always call error() and exception() in a
boolean context anyway, with the same result. (Or actually a slightly
better result than the implementation shown here.)
The obvious downside is that it now uses more storage, which might
hinder some inlining cases.
