Fold Expressions

While implementing a logging facility I recently stumbled across a problem that can be reduced to the following: Inside a variadic function template, if the log level is high enough, forward all arguments into an ::std::ostream&. Dutifully I solved it in a recursive fashion:

1inline log(loglevel_t min_level) { }
2
3template<typename T, typename... V>
4void log(loglevel_t min_level, T&& arg, V&& more_args) {
5    if(min_level <= current_level) {
6        out << ::std::forward<T>(arg);
7        log(min_level, ::std::forward<T>(more_args);
8    }
9}

However, not only does that feel like a clutch - after all I really just want to push everything into the output stream - but it also requires the instantiation of all those additional functions, which causes the executable to grow larger than necessary¹.

After a bit of playing around, I decided to cheat a bit by abusing the comma operator to create an initializer list filled only with zeros, which I then simply never use. Any compiler worth its salt should then optimize the overhead away, leaving me with a small binary and a definition that matches my intent better:

1template<typename... V>
2void log(loglevel_t min_level, T&& arg, V&& args) {
3    if(min_level <= current_level) {
4        ::std::initializer_list<int> _ =
5            {(out << ::std::forward<V>(args), 0)...};
6        static_cast<void>(_);
7    }
8}

Going through this one by one, it should be fairly obvious that the variable _ is only used to bind the initializer list to, but never actually used. The initializer list consists of the unpacking of the part in parentheses, which does nothing more than first pushing the current argument into out, and then returning 0².

However, not only this this a workaround for the fact that I cannot simply unpack the parameters at block scope (instead, the result of the unpacking needs to go somewhere), but it also really generates a different kind of result than I would write by hand. How come? Well by hand, I would write:

out << arg1 << arg2 << arg3;

But the above really performs something more similar to:

1out << arg1;
2out << arg2;
3out << arg3;

Still, to the best of my knowledge that is the best that one can do with C++14. However, the upcoming C++1z standard is expected to bring fold expressions  to the table, which could then finally be used to express what I really want to say, using a syntax that reminds me a lot of how I would write something like this as a mathematical expression:

1template<typename... V>
2void log(loglevel_t min_level, T&& arg, V&& args) {
3    if(min_level <= current_level) {
4        out << ... << ::std::forward<V>(args); // works as expected
5    }
6}

There are four different kinds of fold expressions that will be supported. The binary fold expressions already explored above accounts for two of them: Those were the parameter pack is on the left hand side, and those where it is on the right hand side. Besides the obvious difference (where the initial element ends up), they also differ in whether the expression is evaluated left to right or right to left, as the initial (non-parameter-pack) value is always innermost in the resulting expression. This has the useful side-effect that out << ... << ::std::forward<V>(args) is unpacked as (out << ::std::forward<V<sub>1</sub>>(args<sub>1</sub>)) << ::std::forward<V<sub>2</sub>>(args<sub>2</sub>).

Additionally, there are unary fold expressions, which - despite their name - does not actually work on unary operators, but really are just binary folds without an initial value. A unary right fold is written as pack op ... while a unary left fold is written as ... op pack. The difference is only in the order in which the operation is unfolded; a unary right fold will apply the op first to the rightmost elements of the pack, and a unary left fold will apply the op first to the leftmost elements of the pack. For example:

if(... && args)

Will, when having three actual elements, be unpacked to something similar to:

if(((args<sub>1</sub> && args<sub>2</sub>) && args<sub>3</sub>) && args<sub>4</sub>)

On the other hand

if(args && ...)

would be unpacked to something similar to:

if(args<sub>1</sub> && (args<sub>2</sub> && (args<sub>3</sub> && args<sub>4</sub>)))

Of course, this would cause problems with empty parameter packs, which is why the proposal for fold expressions  adds a table of values that are to be returned in case of an unary fold of an empty parameter pack. Logically, the values are chosen as the neutral elements of the binary operator in question (e.g., a 0 for addition and a 1 for multiplication), leading to the alternative (arguably technically false) definition that a unary fold expression is just a shortcut for a binary fold with the neutral element of the operation as the implicit initial value. To illustrate:

1if(args && ...) { } // unary fold that unpacks to:
2if(args<sub>1</sub> && (args<sub>2</sub> && (args<sub>3</sub> && args<sub>4</sub>))) { }
3
4if(args && ... && true) { } // equivalent binary fold unpacks to:
5if(args<sub>1</sub> && (args<sub>2</sub> && (args<sub>3</sub> && (args<sub>4</sub> && true)))) { }

However, while this makes sense mathematically, it may give rise to a non-obvious idiom to deal with an important case:

1if(sizeof...(V) && (some_condition(args) && ...)) {
2    // only execute if arguments exist and satisfy a condition
3}

Personally I think that while this is definitely a step in the right direction, the unpacking of parameter packs still feels somewhat restricted in general.