standard template for returning a value with a boolean result flag

Question

As I am beginning to take advantage of the C++17 structured bindings and if operator init statements for more elegant function result reporting and checking, I started doing the following, if accordance with C++ Core Guideline F21:

std::pair<bool, int>Foo()
{
    return {true, 42}; //true means that function complete with no error and that 42 is a good value
}

void main(void)
{
    if (auto [Result, Value] = Foo(); Result)
    {
        //Do something with the return value here
    }
}

Then, of course, I though that it would be nice to have a reusable template for such return types so that nobody has to duplicate bool portion of the pair:

template <typename T> using validated = std::pair<bool,T>;

validated<int> Foo()
{
    return {true, 42};
}

void main(void)
{
    if (auto [Result, Value] = Foo(); Result)
    {
        //Do something with the return value here
    }
}

This works great for me, but now I am wondering if there is some sort of standard equivalent of this template so that I don't have to reinvent the wheel and define it myself. Seems like an arbitrary type value coupled with a validity flag would be a useful construct, but I could not find anything in standard library. Am I missing something?

luk32 · Accepted Answer · 2018-11-13T17:28:18.220

9

std::optional is exactly what you are asking about. It's even in the description:

A common use case for optional is the return value of a function that may fail. As opposed to other approaches, such as std::pair<T,bool>, optional handles expensive-to-construct objects well and is more readable, as the intent is expressed explicitly.

The if from the example would look a bit more straightforward:

#include <optional>
#include <iostream>

std::optional<int> Foo(bool fail)
{
    if (!fail) return {42};
    return {};
}

void process(bool fail) {
    if (auto val = Foo(fail)) {
        std::cout << val.value() << '\n';
    } else {
        std::cout << "No value!\n";
    }    
}

int main() {
    std::optional<int> oi;
    process(true);
    process(false);
}

If you really wished to use Value explicitly then you can always unpack it via reference on a successful branch i.e. auto Value = val.value();

You need to beware of some caveats. 2 from the top of my head:

Performance: Why is the construction of std::optional<int> more expensive than a std::pair<int, bool>? although for the given example up-to-date clang with -O3 looks pretty convicing

Note: static was added for process for brevity - to prevent generation of version for external linking.
It will return false if object was default constructed. That might surprise some, default construction of optional doesn't default construct underlying value.

EDIT: After the comments I decided to explicitly state that there isn't anything like type alias for pair<T,bool> or similar compatible with standard library. It's not easy to prove something does not exist, but if there would such a type the standard library would most certainly used it in declaration of insert, it doesn't; hence, I strongly imply that there isn't any semantic wrapper around it.

edited Nov 13 '18 at 17:28

answered Nov 13 '18 at 14:49

luk32

15,812
38
62

I think OP is interested in a type alias that works with existing APIs, such as `std::map::insert`. `std::optional` obviously doesn’t work here. – Konrad Rudolph Nov 13 '18 at 15:05
std::optional is a pretty good find, thank you. However, I agree with the comment above, a compatibility with existing return types within the standard library itself would be desirable, I didn't think about it initially. Besides, looking at the source code of std::optional, it seems quite heavy-weight for the simple task at hand. So yes, a type alias to std::pair that would be already defined in the standard library, would be the best. Any suggestions? – Regus Pregus Nov 13 '18 at 15:21
@RegusPregus In what way you perceive it heavy? It acutally has less overhead in case of not having a value. `pair` has to construct an object that is a quite a drawback. IMHO standard library uses `pair` for historical reasons, i.e. there were no `optional` before c++17 but that is the idiomatic way now. – luk32 Nov 13 '18 at 16:31
@KonradRudolph Yea, but I think the core guideline example is more of a work-around for that fact, rather than an encouragement to use `pair`. I honestly don't think there are any advantage of `pair` over `optional`, unless a particular implementation bites you performance wise. One of interesting implementations is [this one](https://akrzemi1.wordpress.com/2015/07/15/efficient-optional-values/) which codes no-value as a reserved value of held type. I'd consider it for built-in types to save space, but this is nothing standard. – luk32 Nov 13 '18 at 17:59
@RegusPregus Don’t be scared off: `std::optional` can be incredibly lightweight. Despite the entirely correct caveats in this answer, its implementation can often be as efficient as your `std::pair` code — subject to library QoI. – Konrad Rudolph Nov 13 '18 at 19:26

score 2 · Answer 2 · answered Nov 14 '18 at 09:51

You might be interested in the proposed std::expected.

Its interface follows std::optional pretty closely. The major advantage of expected<T, E> over optional<T> is the ability to transport an error:

enum class errc {err1, err2, err3};

std::expected<int, errc> Foo()
{
  if (/* error condition 1 */)  return std::unexpected(errc::err1);

  // ... checking other error conditions

  return 42;  // no error condition (42 is a good value)
              // implicit conversion from `int` to `expected<int, errc>`
              // avoid boilerplate code
}

int main()
{
  auto q = Foo();

  if (q)
  {
    // Do something with the return value here
  }
}

You could also take a look at:

Functional exceptionless error-handling with optional and expected;
the standard proposal;
A possible implementation.

As a side note main() must return int.

standard template for returning a value with a boolean result flag

2 Answers2