Abstract

This proposal recommends the relaxing of [dcl.fct]¶11; specifically, the prohibition of defining (anonymous) types as return values, and adding a mechanism that simplifies naming the return type of a previously declared function. These features were previously proposed separately, as P0222 and P0224.

Rationale

The concept of multiple return values is well known. At present, however, C++ lacks a good mechanism for implementing the same. std::tuple is considered clunky by many and, critically, creates sub-optimal API by virtue of the returned values being unnamed, forcing developers to rely on supplemental documentation to explain their purpose. Aggregates represent an improvement, being self-documenting, but the need to provide external definitions of the same is awkward and, worse, pollutes their corresponding namespace with entities that may be single use. Proposals such as N4560 present a complicated mechanism for providing tagged (self-documenting) tuple-like types, which may be necessary in some cases, but still represent a non-trivial amount of complexity that ideally should not be required. P0341 presents a similar idea with tagged parameter packs as return values.

The addition of decomposition declarations in C++17 in particular represents a significant step toward support of multiple return values as first class citizens. This feature, along with other ongoing efforts to add first class support for "product types" and other efforts such as P0341 show an encouraging movement away from the traditional std::pair and std::tuple towards comparable concepts without requiring the explicit types. (We expect, however, that the standard template library types will remain useful for algorithms where the identity of the elements is unimportant, while it is important to be able to name at least the outer, if not complete, type. In that respect, we hypothesize that we may in the future see the ability to construct a std::tuple from any tuple-like, as also suggested in P0197.)

On their own, however, these directions risk exacerbating the problem that this proposal aims to address. In particular, a concern with the notion of returning a parameter pack, as presented in P0341, is that it opens a potential ABI can of worms. Moreover, parameter packs are not true types, and are subject to significant limitations, such as inability to make copies or pass them around as single entities, which are not shared by regular compound types. With generalized unpacking (P0535), product types and parameter packs are effectively interchangeable, and returning a product type rather than a parameter pack leverages existing ABI and techniques, rather than introducing something entirely novel. The remaining issue is one of naming; naming things — in this case, return types, especially for one-off functions — is hard.

It has been suggested on multiple occasions that the optimal solution to the above issues is to return an anonymous struct. This solves the problems of clutter and self-documentation, but runs afoul of a much worse issue; because the struct is anonymous, it can be difficult to impossible to give its name a second time in order to separate the declaration and definition of the function that wishes to use it. This, however, leads to a more interesting question: why is it necessary to repeat the return value at all?

Even in the case of return types that can be named, it may be that repeating the type name is excessively verbose or otherwise undesirable. Some might even call this a violation of the Don't Repeat Yourself principle, similar to some of the issues that auto for variable declaration was introduced to solve. (On the flip side, one could see the ability to elide the return type as subject to many abuses, again in much the manner of auto. However, many language features can be abused; this should not prevent the addition of a feature that would provide an important benefit when used correctly.)

While it is already possible in simple cases to use decltype and a sample invocation of the function, this is needlessly verbose, and as the argument list grows longer, it can quickly become unwieldy.

While both these features have use on their own, they are nevertheless related, and we believe that presenting them together makes sense, and strengthens the case for each.

Proposal

We propose, first, to remove the restriction against (anonymous) types as return values:

struct { int id; double value; } foo() { ... }

We believe this can be accomplished largely by simply removing the prohibition in [dcl.fct]¶11.

Second, we propose the addition of decltype(return) to name — in a function signature — the return type of a previously declared function. This is consistent with recent changes to the language that have progressively relaxed the requirements for how return types are specified, and provides an optimal solution to the following problem:

// foo.h
struct { int id; double value; } foo();

How does one now provide an external definition for foo()? With our proposal, the solution is simple:

// foo.cpp
decltype(return) foo()
{
  ...
  return { id, value };
}

Naturally, "previous declared" here means a declaration having the same name and argument list. This, for example, would remain illegal:

int foo(int);
float foo(float);

decltype(return) foo(double input) // does not match any previous declaration
{
  ...
  return result;
}

The reasons to prohibit an anonymous struct defined as a return type have also been significantly mitigated. Constructing the return result is a non-issue, since the type name may now be elided, and the combination of auto variable declarations, decltype, and the proposed mechanism for naming the return type in a function signature permit implicit naming of the type where necessary. In short, the prohibition ([dcl.fct]¶11) against defining types in return type specifications has become largely an artificial and arbitrary restriction which we propose to remove.

We additionally note that this prohibition is already not enforced by at least one major compiler (MSVC), and is enforced sporadically in others (see What about defining types in function pointer types?).

Interactions

Definition of a class-type as a return value type is currently ill-formed (although not universally enforced by existing major compilers), and the token sequence decltype(return) is currently ill-formed. Accordingly, this change will not affect existing and conforming code, and may cause existing but non-conforming code to become conforming. This proposal does not make any changes to other existing language or library features; while conceivable that some library methods might benefit from the feature, such changes are potentially breaking, and no such changes are proposed at this time.

Implementation and Existing Practice

The proposed feature to allow defining types (including anonymous types) during return value specification is already at least partly implemented by MSVC and (to a lesser extent) GCC and ICC, and is also partly conforming to C++14. The trick shown in Can't we do this already? as well as the curious, partial support in GCC and ICC (see What about defining types in function pointer types?) suggests that the existing prohibition may already be largely artificial, and that removing it would accordingly be a simple matter.

The proposed feature to allow decltype(return) to name the return value has not, to our knowledge, been implemented, but given that compilers must already compare the return value when confronted with an initial declaration followed by subsequent redeclarations and/or a definition, we do not anticipate any implementation difficulties.

Discussion

auto f()
{
  struct { int x, y; } result;
  // set values of result
  return result;
}

// Equivalent to struct S { ... }; S foo();
struct S { ... } foo();

template<class T>
struct {
    size_t s;
} // Declaring a templated type, right?
what_size(T t) {
    return {sizeof(t)};
}

auto foo -> struct { ... };
template<...> auto bar -> struct { ... };

// Declare a function pointer type which returns an anonymous struct
using ReturnsAnonymousStruct = struct { int result; } (*)();

// Define a function using the same
int bar(ReturnsAnonymousStruct f) { return ((*f)()).result; }

// Provide a mechanism to obtain the return type of a function
template <typename T> struct ReturnType;

template <typename T, typename... Args>
struct ReturnType<T (*)(Args...)>
{
    using result_t = T;
};

// Declare a function that is a ReturnsAnonymousStruct
ReturnType<ReturnsAnonymousStruct>::result_t foo() { return {0}; }

// Use the function
int main()
{
    return bar(&foo);
}

struct { int result; } foo() { ... }
struct { int result; } bar()
{
  return foo();
}

struct { int result; } bar()
{
  return { [:]foo()... };
}

auto foo()
{
  return { .x = 3, .y = 2 }; // deduce: struct { int x, y; }
}

Future Directions

In the Discussion section above, we presented a utility for extracting the return type from a function pointer type. The facility as presented has significant limitations; namely, it does not work on member functions and the several variations (e.g. CV-qualification) which apply to the same. We do not here propose a standard library implementation of this facility, which presumably would cover these cases, however there is room to imagine that such a facility could be useful, especially if the proposals we present here are adopted. (David Krauss points out that std::reference_wrapper can be used to similar effect... on some compilers. However, imperfect portability and the disparity between intended function and use for this result suggest that this is not the optimal facility for the problem.)

Another consideration that seems likely to come up is if we should further simplify the syntax for returning multiple values (conceivably, this could apply to both anonymous structs and to std::pair / std::tuple). Some have suggested allowing that the struct keyword may be omitted. In light of P0151 and P0341, we can conceive that allowing the syntax <int x, double y> foo() might be interesting (in contrast to P0341, we would suggest that this be shorthand for std::tuple if the names are omitted). At this time, we prefer to focus on the feature here presented rather than risk overextending the reach of this proposal. However, if this proposal is accepted, it represents an obvious first step to considering such features in the future.

A final consideration is the extension of decltype(return) to allow use within a function body. At the time of writing, we are not aware of a proposal to do so, although the idea has been floated on numerous occasions. We would hope to see such an addition, which can be orthogonal to this proposal, in the near future. (This also serves as an additional argument for using decltype(return) to name the return value rather than auto.)

Acknowledgments

We wish to thank everyone on the std-proposals forum, especially Bengt Gustafsson, Arthur O'Dwyer and R. "Tim" Song, for their valuable feedback and insights.

References

• N4618 Working Draft, Standard for Programming Language C++

  http://wg21.link/n4618

• N4560 Extensions for Ranges

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4560.pdf

• P0151 Proposal of Multi-Declarators (aka Structured Bindings)

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0151r0.pdf

• P0197 Default Tuple-like Access

  http://wg21.link/p0197

• P0222 Allowing Anonymous Structs as Return Values

  http://wg21.link/p0224

• P0224 Implicit Return Type

  http://wg21.link/p0224

• P0329 Designated Initializer Wording

  http://wg21.link/p0329

• P0341 Parameter Packs Outside of Templates

  http://wg21.link/p0341

• P0535 Generalized Unpacking and Parameter Pack Slicing

  http://wg21.link/p0535