Is it safe to handle a std::optional in the body of a noexcept function?

Question

I wanna use std::optional as a Maybe type and I'm concerned wether I can use it to indicate a potential failure in some computation, the so observed as an empty option.

For example, consider:

// This function doesn't have state
std::optional<int> multiply_by_2(std::optional<int> ox) noexcept
{
    if (ox)
        return {ox.value() * 2};

    // empty input case
    return {};
}

int main()
{
    auto input_handle = get_stdin().lock();
    auto output_handle = get_stdout().lock();

    // This can panic the application, which is fine at this point
    // so just unwrap the optional and call it a day
    output_handle.println("Your marvellous calculation: {}", multiply_by_2(input_handle.get_line().as_int()).value());
}

• Is this an efficient techinique for returning computations? Can it avoid some exception bloat?
• Can this cause any trouble?

Answer 1

There seem to be a few questions here.

1. Is it safe to handle a std::optional in the body of a noexcept function?

Yes, so long as the type T, wrapped by std::optional, is nothrow copy constructible.

In this code:

if (ox)
    return {ox.value() * 2};

since you are checking before calling std::optional::value(), an exception will never be thrown. That being said, since you're already sure that the ox.has_value(), it's better to use the operator*:

if (ox)
    return {*ox * 2};

That way the compiler won't need to generate the precondition check and the throw std::bad_optional_access statement (in simple cases the compiler can optimize that out based on if (ox) but why make the compiler do more work).

2. Is this an efficient technique for returning computations? Can it avoid some exception bloat?

Presumably, by "exception bloat" you mean the binary size overhead from all the exception handling code that the compiler needs to generate. If for whatever reason you really care about this, then yes - the std::optional technique can avoid that bloat at the cost of more overhead when no errors occur.

That's the trade-off you have to accept with this style error handling (std::optional, std::error_code, Outcome, etc.). You agree to a constant overhead on success in order to get constant overhead on failure. Exceptions, on the other hand, only incur an overhead (non-deterministic in time and space) on failure.

In this particular case you would probably be better off not polluting a simple function that otherwise cannot fail with error handling. Instead defer that to the caller. After all the caller might already know that the value exists.

3. Can this cause any trouble?

The main issue here is the lack of any information about the error. std::optional can't convey the reason the operation failed. In a trivial application this may not be an issue, but as soon as you start composing more complex operations, problems with tracking down the cause of failure will become apparent.

Even in this code there are a few error conditions that may be useful to report appropriately: IO errors and parsing errors. And then among parsing errors:

• the input may not be a valid number;
• the number may exceed the range of int.

Assuming you end up not using exceptions, consider using something like the proposed std::expected or the Outcome library.

I wouldn't recommend just using a std::variant (at least not without wrapping it) as it does not convey the intent of error handling. Also, it doesn't support holding void.

Answer 2

Exceptions are a touchy topic in C++ with several different opinions about it. I'm aware that there are standardization proposals in flight (c++23 or later) to improve a lot about them and you are right that they ain't zero overhead.

However, no system will be completely zero overhead as you do need error handling and checking at several places.

To me, using std::optional is plain wrong, because there ain't any information: It went wrong, please attach a debugger to find out why. I'm more in favor of a exception like structure that has either a value or a failure info. std:: variant comes to mind. Off course, without reporting it, you still need a debugger to understand what went wrong.

That said, if you don't mind this, your code will be fine for functionality and performance. What I do wonder is: do you need to use optional as an argument? You currently chain one after the other, and with function overloading, you could provide a smaller implementation:

// This function doesn't have state
 int multiply_by_2(int ox) noexcept
{
    return ox * 2;
}

// This function doesn't have state
std::optional<int> multiply_by_2(std::optional<int> ox) noexcept
{
    if (ox)
        return multiply_by_2(ox.value());

    // empty input case
    return std::nullopt;
}

This way, you have less overhead if you're input can't be a failure.

Finally: make sure these methods are visible to the caller. As you don't check your error path, you would have UB in case of failure. I haven't checked, though compilers might be able to remove the failure path through your function as it cannot be used in a confirming program.