Policy-based design is a great way for library authors to provide more flexibility to the user. Instead of hard coding certain behaviors, policy-based design provides various policies the users can select to customize the behavior. If done properly, a library author can accommodate all use cases with a single implementation.

I’m a big fan of policy-based design for that reason. Whenever there’s a possible trade-off, where multiple solutions are possible, each with their own set of advantages and disadvantages, I make the decision available to the user. Instead of favoring a certain use case, I favor all of them. This is for example what I did with my variant implementation.

However, policy-based design isn’t perfect. In particular, it has a great problem: It creates lots and lots of different and incompatible types.

I’ve recently read this blog post by Vittorio Romeo. He talks about various ways to pass a function (callback, comparator for algorithm, etc.) to another function. One of them is function_view. function_view is a lightweight std::function: it should be able to refer to any callable with a given signature. But unlike std::function it does not own the callable, just refers to it. This allows a much more efficient implementation.

In this post he presented one. But his has a flaw, that can bite you very easily.

While browsing the C++ subreddit I’ve encountered the following comment.

I’m not going to jump on the exception discussion currently happening in the child comments. I’m just going to focus on the part where he said it is sad that C++ constructors require exceptions for error handling. So let’s assume you don’t have exception support in your application and has a constructor that needs to report an error. What do you do?

C++17 is going to add std::variant. To quote the linked documentation, it is a “type-safe union”. A union is like a struct, but can only store one member at a time. This has many applications, but sadly it doesn’t mix well with non-trivial types, you have to call the destructor yourself etc. Furthermore, nothing prevents you from accessing a union member that isn’t active.

std::variant fixes that. It correctly calls the destructor when switching the active member, it prevents invalid access, etc. However, I’m not quite happy with it and I needed an implementation now. So I’ve decided to implement my own variant as part of my type_safe library.

It was a fun challenge and since my previous attempt was two years ago, I could improve it a lot. Let’s go through some of my design decisions.

Consider that you have a function template that takes a parameter on type T. If the function template has a rather generic name like operator==, is a constructor, or anything whose existence might be queried with type traits to further constrain other functions, it is often beneficial if you can conditionally disable the function if the type does not have some required properties. Otherwise the function will be “greedy” and accept more than it should - making some traits near useless, as they only check for existence and the error only occurs later.

Conditionally removing functions if their template parameters don’t fulfill certain properties is done with SFINAE. But what if you have member functions of a class template that are not templates themselves?