Trailing Return Types

In our earlier lessons on template functions, we introduced scenarios where we don’t necessarily know what the return type of the instantiated function will be. This is because the specific return type will depend on the type of the arguments.

In many simple scenarios, we can get around this simply by setting the return type to auto, asking the compiler to figure it out based on our return statements:

1#include <iostream>
2
3template <typename T1, typename T2>
4auto Multiply(T1 x, T2 y){ return x * y; }
5
6int main(){
7  std::cout << "Double: " << Multiply(2.4, 3.2);
8  std::cout << "\nInt: " << Multiply(2, 3);
9}

1Double: 7.68
2Int: 6

But in more complex scenarios, this is not enough.

The Problem with Return Types

Let's consider a simple, contrived addition to our function where we want to return a zero-initialized object based on a conditional check:

1#include <iostream>
2
3template <typename T1, typename T2>
4auto Multiply(T1 x, T2 y){
5  if (x == 0 || y == 0) return 0;
6  return x * y;
7}
8
9int main(){
10  std::cout << "Double: " << Multiply(2.4, 3.2);
11}

In this situation, we now have one branch of our generated function returning an int, whilst another returns a double. With a defined return type, this is not necessarily a problem. The compiler can cast what is returned by the return statement into the function’s returned type.

But, with an auto return type, the compiler no longer knows what object it needs to return. And, when different branches of our function return different types, it doesn’t know what to do and throws an error:

1all return expressions must deduce to the same type

We could try solving this problem by coercing our return value to one of our template types. For example, we could explicitly call a type constructor in our return statement:

1template <typename T1, typename T2>
2auto Multiply(T1 x, T2 y) {
3  if (x == 0 || y == 0) return T1(0);
4  return x * y;
5}

Or we could replace the auto return type with one that matches one of our template parameters:

1template <typename T1, typename T2>
2T1 Multiply(T1 x, T2 y) {
3  if (x == 0 || y == 0) return 0;
4  return x * y;
5}

This will let our program compile, but now the return type of our multiplication function, and therefore its arithmetic value, depends on the order of our parameters:

1#include <iostream>
2
3template <typename T1, typename T2>
4T1 Multiply(T1 x, T2 y){
5  if (x == 0 || y == 0) return 0;
6  return x * y;
7}
8
9int main(){
10  std::cout << "First: " << Multiply(2.1, 2);
11  std::cout << "\nSecond: " << Multiply(2, 2.1);
12}

1First: 4.2
2Second: 4

Additionally, these techniques aren’t always an option. They require our return type to be the same as one of our argument types.

That is not always possible. Were we to be multiplying matrices, the type of matrix that is returned is not necessarily the same type as either of the arguments.

For example, multiplying a 3x1 matrix by a 1x3 matrix results in a 3x3 matrix, which would be an entirely different type in almost any implementation:

1int main(){
2  Matrix<3, 1> A{1, 2, 3};
3  Matrix<1, 3> B{4, 5, 6};
4  Matrix<3, 3> C{Multiply(A, B)};
5}

So, we need a better way to solve this problem.

decltype()

In our earlier lessons, we introduced decltype, which lets us deduce a type at compile time, based on an expression.

In this excessively contrived example, we show how we can use decltype to construct a type based on the types of our arguments:

1auto Multiply(int x, int y) {
2  using ReturnType = decltype(x * y);
3  return ReturnType { x * y };
4}

We can also remove the intermediate type alias if preferred:

1auto Multiply(int x, int y) {
2  return decltype(x * y) { x * y };
3}

Within regular functions, this is rarely useful, but it becomes very helpful when writing function templates. For example, it can be used to solve the problem we introduced at the start of this section:

1#include <iostream>
2
3template <typename T1, typename T2>
4auto Multiply(T1 x, T2 y) {
5  if (x == 0 || y == 0) {
6    return decltype(x * y){0};
7  }
8  return x * y;
9}
10
11int main(){
12  std::cout << "First: " << Multiply(2.1, 2);
13  std::cout << "\nSecond: " << Multiply(2, 2.1);
14
15  auto ReturnValue{Multiply(0.0, 0.0)};
16  std::cout << "\nZero-Initialization: "
17    << ReturnValue
18    << " ("
19    << typeid(decltype(ReturnValue)).name()
20    << ")";
21}

1First: 4.2
2Second: 4.2
3Zero-Initialization: 0 (double)

This works correctly, however, it is somewhat indirect. If we know the return type of a function, we’d ideally like that return type to be part of the function signature. Were we to attempt this decltype technique with the regular function syntax, we’d run into an issue, as the return type comes before the parameter list:

1decltype(x * y) Multiply(int x, int y) {
2  return x * y;
3}

This results in the usual compilation error we’d get from trying to use an identifier before it was declared:

1'x': undeclared identifier
2'y': undeclared identifier

So, we need an alternative syntax that moves the function’s return type after the parameter list.

Using Trailing Return Types

The following shows a minimalist example of a function that uses a trailing return type. We use the auto keyword in place of the traditional return type. We then then place the return type between the function’s parameter list and the body, using an arrow -> syntax.

1auto GetNumber() -> int {
2  return 42;
3}

When our function has parameters, it looks like this:

1auto Add(int x, int y) -> int {
2  return x + y;
3}

The benefit of the trailing return type is that it now has access to those parameters. This lets the compiler infer the return type based on those values:

1auto Add(int x, int y) -> decltype(x + y) {
2  return x + y;
3}

Function Templates

The trailing return type syntax is most useful within template functions, where we don’t necessarily know the parameter types when we’re creating the template function.

The following example fixes our earlier problem, by allowing us to correctly determine the return type based on an expression involving our parameters:

1#include <iostream>
2
3template <typename T1, typename T2>
4auto Multiply(T1 x, T2 y) -> decltype(x * y){
5  if (x == 0 || y == 0) return 0;
6  return x * y;
7}
8
9int main(){
10  std::cout << "First: " << Multiply(2.1, 2);
11  std::cout << "\nSecond: " << Multiply(2, 2.1);
12
13  auto ReturnValue{Multiply(0.0, 0.0)};
14  std::cout << "\nZero-Initialization: "
15    << ReturnValue
16    << " ("
17    << typeid(decltype(ReturnValue)).name()
18    << ")";
19}

1First: 4.2
2Second: 4.2
3Zero-Initialization: 0 (double)

Naturally, this also scales to more complex types. Below, we’ve added a new class. Without modifying our template function at all, it still works as expected, returning a type that doesn’t match either of the argument types but is still derived from them.

Note that the following Matrix class template is nowhere near complete, as that’s not our focus. It is only implemented to the extent that demonstrates the behavior of our Multiply template function.

The class also uses static variables, which may be unfamiliar at this stage. We have a dedicated lesson on later in the course:

1#include <iostream>
2
3template <int R, int C>
4class Matrix {
5public:
6  static const int Rows{R};
7  static const int Cols{C};
8
9  // Constructors
10  Matrix(){}
11  Matrix(int){}
12
13  // Operators
14  bool operator==(int){ return true; }
15
16  template <typename T>
17  auto operator*(T Other){
18    return Matrix<Rows, Other.Cols>{};
19  }
20};
21
22template <typename T1, typename T2>
23auto Multiply(T1 x, T2 y) -> decltype(x * y){
24  if (x == 0 || y == 0) return 0;
25  return x * y;
26}
27
28int main(){
29  Matrix<3, 1> A;
30  Matrix<1, 3> B;
31  auto Result{Multiply(A, B)};
32
33  std::cout
34    << "Rows: " << Result.Rows
35    << "\nColumns: " << Result.Cols;
36}

1Rows: 3
2Columns: 3

Member Functions

Within class methods, we can use trailing return types in the same way.

1class Character {
2public:
3  auto GetName() -> std::string {
4    return Name;
5  }
6
7private:
8  std::string Name;
9};

However, there are some interactions with qualifiers such as const, override, and final we need to note.

The const qualifier needs to go before the return type, whilst override and final appear after:

1class Character {
2public:
3  virtual auto GetName() const -> std::string {
4    return Name;
5  }
6
7  virtual auto GetLevel() const -> int {
8    return Level;
9  }
10
11private:
12  std::string Name;
13  int Level;
14};
15
16class Monster : public Character {
17public:
18  auto GetName() const -> std::string override {
19    // do monster things, then...
20    return Character::GetName();
21  }
22
23  auto GetLevel() const -> int final {
24    // do monster things, then...
25    return Character::GetLevel();
26  }
27};

Using Trailing Return Types by Default

Within the community, the use of the trailing return type is gaining traction as the default way of defining functions, even in scenarios where it is not required.

There are two main arguments that supporters of the convention use.

Firstly, having the parameter types before the return type is often a more intuitive way of ordering information. It maps to how we typically think about functions ("this function accepts x and returns y") and also how functions behave (they use their parameters, and then they return).

The second reason is that, within a long list of function declarations, using a trailing return type causes the function names to visually align. This can make scanning class definitions to understand their capabilities a more pleasant experience:

1// Before
2class Character {
3public:
4  const std::string& GetName() const;
5  void SetName(std::string);
6  int GetLevel() const;
7  void SetLevel(int);
8  std::shared_ptr<Party> GetParty() const;
9  void SetParty(std::shared_ptr<Party>);
10};
11
12// After
13class Character {
14public:
15  auto GetName() const -> const std::string&;
16  auto SetName(std::string) -> void;
17  auto GetLevel() const -> int;
18  auto SetLevel(int) -> void;
19  auto GetParty() const -> std::shared_ptr<Party>;
20  auto SetParty(std::shared_ptr<Party>) -> void;
21};

This example also shows the main drawback of the trailing return type syntax - it simply requires more code. This is mostly due to the requirement that we need to include the auto keyword at the start of every declaration.

As such, there is generally no agreed recommendation here. Most teams will have their own agreed standard, otherwise, we should feel free to use whichever pattern we prefer.

Summary

This lesson introduced trailing return types, enabling more flexible function declarations, especially in templates and complex type deduction scenarios. The key topics we learned include:

• The basics of trailing return types and their syntax, using auto and ->.
• How to use trailing return types to overcome limitations of auto return type deduction in functions with conditional or complex returns.
• The use of decltype in conjunction with trailing return types to accurately deduce and specify return types in template functions.
• Implementing trailing return types in class methods, including interactions with qualifiers such as const, override, and final.
• The advantages and considerations of adopting trailing return types as a standard practice, even in scenarios where they’re not required

Next Lesson

Recursion and Memoization

An introduction to recursive functions, their use cases, and how to optimize their performance

ContinueView Course