Abstract

We propose a new mechanism for specifying or deducing the value category of an instance of a class. In other words, a way to tell from within a member function whether the object it’s invoked on is an lvalue or an rvalue, and whether it is const or volatile.

1. Motivation

In C++03, member functions could have cv-qualifications, so it was possible to have scenarios where a particular class would want both a const and non-const overload of a particular member (Of course it was possible to also want volatile overloads, but those are less common). In these cases, both overloads do the same thing - the only difference is in the types accessed and used. This was handled by either simply duplicating the function, adjusting types and qualifications as necessary, or having one delegate to the other. An example of the latter can be found in Scott Meyers' "Effective C++", Item 3:

Arguably, neither the duplication or the delegation via const_cast are great solutions, but they work.

In C++11, member functions acquired a new axis to specialize on: ref-qualifiers. Now, instead of potentially needing two overloads of a single member function, we might need four: &, const&, &&, or const&&. We have three approaches to deal with this: we implement the same member four times, we can have three of the overloads delegate to the fourth, or we can have all four delegate to a helper, private static member function. One example might be the overload set for optional<T>::value(). The way to implement it would be something like:

It’s not like this is a complicated function. Far from. But more or less repeating the same code four times, or artificial delegation to avoid doing so, is the kind of thing that begs for a rewrite. Except we can’t really. We have to implement it this way. It seems like we should be able to abstract away the qualifiers. And we can... sort of. As a non-member function, we simply don’t have this problem:

This is great - it’s just one function, that handles all four cases for us. Except it’s a non-member function, not a member function. Different semantics, different syntax, doesn’t help.

There are many, many cases in code-bases where we need two or four overloads of the same member function for different const- or ref-qualifiers. More than that, there are likely many cases that a class should have four overloads of a particular member function, but doesn’t simply due to laziness by the developer. We think that there are sufficiently many such cases that they merit a better solution than simply: write it, then write it again, then write it two more times.

2. Proposal

We propose a new way of declaring a member function that will allow for deducing the type and value category of the class instance parameter, while still being invocable as a member function. We introduce a new kind of parameter that can be provided as the first parameter to any member function: an explicit object parameter. The purpose of this parameter is to bind to the implicit object, allowing it to be deduced.

An explicit object parameter shall be of the form T[const][volatile][&|&&]this<identifier>, where T follows the normal rules of type names (e.g. for generic lambdas, it can be auto), except that it cannot be a pointer type. Member functions with explicit object parameters cannot be static or have cv- or ref-qualifiers.

The explicit object parameter can only be the first parameter of a function. It cannot be used in constructors or destructors.

This is a strict extension to the language; all existing syntax remains valid.

For the purposes of this proposal, we assume the existence of two new library functions: a metafunction named like which applies the cv and ref qualifiers from its first type argument onto its second (such that like_t<int&,double> is double&, like_t<Xconst&&,Y> is Yconst&&, etc.), and a function template named forward_like which allows you to forward based on the value category of an unrelated type (forward_like<T>(u) is short-hand for forward<like_t<T,U>>(u)). Sample implementations of both can be seen here.

We believe that the ability to write cv-ref qualifier-aware member functions without duplication will improve code maintainability, decrease the likelihood of bugs, and allow users to write fast, correct code more easily.

What follows is a description of how explicit object parameters affect all the important language constructs: name lookup, type deduction, overload resolution, and so forth.

2.1. Name lookup: candidate functions

Today, when either invoking a named function or an operator (including the call operator) on an object of class type, name lookup will include both static and non-static member functions found by regular class lookup. Non-static member functions are treated as if there were an implicit object parameter whose type is an lvalue or rvalue reference to cvX (where the reference and cv qualifiers are determined based on the function’s qualifiers) which binds to the object on which the function was invoked. For static member functions, the implicit object parameter is effectively discarded, so they will not be mentioned further.

For non-static member functions with the new explicit object parameter, lookup will work the same way as other member functions today, except rather than implicitly determining the type of the object parameter based on the cv- and ref-qualifiers of the member function, these are set by the parameter itself. The following examples illustrate this concept. Note that the explicit object parameter does not need to be named:

The overload resolution rules for this new set of candidate functions remains unchanged - we’re simply being explicit rather than implicit about the object parameter. Given a call to x.ex_foo(), overload resolution would select the first ex_foo() overload if x isn’t const and the second if it is.

Since the first parameter in member functions that have an explicit object parameter binds to the class object on which the member function is being invoked, the first provided argument is used to initialize the second function parameter, if any:

structC{intget(Cconst&thisself,inti);};Cc;c.get(4);// self is a C const&, initialized to c// i is initialized with 4

2.2. Type deduction

One of the main motivations of this proposal is to deduce the cv-qualifiers and value category of the class object, so the explicit object parameter needs to be deducible. We do not propose any change in the template deduction rules for member functions with explicit object parameters - it will just be deduced from the class object the same way as any other function parameter:

Since deduction rules do not change, and the explicit object parameter is deduced from the object the function is called on, this has the interesting effect of possibly deducing derived types, which can best be illustrated by the following example:

When we deduce the object parameter, we don’t just deduce the cv- and ref-qualifiers. We may also get a derived type. This follows from the normal template deduction rules. In #3, for instance, the object parameter is an lvalue of type D, so Self deduces as D&.

2.3. Name lookup: within member functions with explicit object parameters

So far, we’ve only considered how member functions with explicit object parameters get found with name lookup and how they deduce that parameter. Now let’s move on to how the bodies of these functions actually behave. Consider a slightly expanded version of the previous example:

Consider invoking each of these functions with an lvalue of type D. We have no interest in changing template deduction rules, which means that Self in each case will be D&. The design space consists of the following alternatives:

this is a B* (non-const because the explicit object parameter is non-const), unqualified lookup looks in B's scope first. This means that f1 returns an int& (to B::i) and f2 returns an int&. f3 is ill-formed, because std::forward<D&> takes a D& and we’re passing in a B&, which is not a conversion that can be done implicitly. f4 returns a double& to D::i, because while *this is a B, self actually is the object parameter, hence is a D.

this is a D* (non-const), but unqualified lookup looks in B's scope. This means that f1 returns an int&, but f2 returns a double&. f3 and f4 both return double&.

this is a D* and unqualified lookup looks in D's scope too. All four functions return a double&.

While the previous three options are variations on these functions behaving as non-static member functions, we could instead also consider these functions to behave as either static member functions or non-member friend functions. In this case, any member access would require direct access from the explicit object parameter, so f1, f2, and f3 are all ill-formed. f4 returns a double&.

In our view, options 2 and 3 are too likely to be lead to programmer errors, even by experts. It would be very surprising if f1 didn’t return B::i, or if f1 and f2 behaved differently. Option 4 is interesting, but would be more verbose without clear benefit.

We favor option 1, since f1, f2 and f4 all end up having behavior that is reasonable given the other rules for name lookup we already have. f2 and f4 returning different things might appear strange at first glance, but f2 references this->i and f4 references self.i - programmers would have to be aware that these may be different. Where this option could go wrong is f3, which looks like it yields an lvalue or rvalue reference to B::i but is actually casting *this to a derived object. But since this is ill-formed, this is a compile error rather than a runtime bug. Hence, not only do we get typically expected behavior, but we’re also protected from a potential source of error by the compiler.

The proper way to implement forwarding is to use one of the two hypothetical library functions mentioned earlier:

structB{template<typenameSelf>auto&&f3(Self&&thisself){returnstd::forward<Self>(*this).i;// ok if Self and *this are the same type// compile other if Self is a derived typereturnstd::forward<like_t<Self,B>>(*this).i;// always okreturnstd::forward_like<Self>(*this).i;// always ok}};

The rule that we’re establishing is that this remains a pointer to the class type of the member function it is used in, and unqualified lookup looks in class scope as usual. Additionally, this is either a pointer to the explicit object parameter or, in the case of deducing a derived type, one of its base class subobjects.

2.4. By-value explicit object parameters

We think they are a logical extension of the mechanism, and would go a long way towards making member functions as powerful as inline friend functions, with the only difference being the call syntax. One implication of this is that the explicit object parameter would be move-constructed in cases where the object is an rvalue (or constructed in place for prvalues), allowing you to treat chained builder member functions that return a new object uniformly without having to resort to templates.

We continue to follow the rule established in the previous section: this is a pointer to the explicit object parameter or one of its base class subobjects. In the example below, this==&self and all accesses to s could also be rewritten as this->s or self.s:

classstring_builder{std::strings;operatorstd::string(string_builderthisself){returnstd::move(s);}string_builderoperator*(string_builderthisself,intn){assert(n>0);s.reserve(s.size()*n);autoconstsize=s.size();for(autoi=0;i<n;++i){s.append(s,0,size);}returnself;}string_builderbop(string_builderthisself){s.append("bop");returnself;}};// this is optimally efficient as far as allocations gostd::stringconstx=(string_builder{"asdf"}*5).bop().bop();

In this example, x would hold the value "asdfasdfasdfasdfasdfbopbop".

Of course, implementing this example with templated explicit object parameter member functions would have been slightly more efficient due to also saving on move constructions, but the by-value usage makes for simpler code.

2.5. Writing the function pointer types for such functions

All the member functions that take references already have a function pointer syntax - they are just alternate ways of writing functions we can already write.

The only one that does not have such a syntax is the pass-by-value method, all others have pre-existing signatures that do just fine.

We are asking for suggestions for syntax for these function pointers. We give our first pass here:

structZ{// same as int f(int a, int b) const&;intf(Zconst&this,inta,intb);intg(Zthis,inta,intb);};// f is still the same as Y::fstatic_assert(std::is_same_v<decltype(&Z::f),int(Z::*)(int,int)const&>);// but would this alternate syntax make any sense?static_assert(std::is_same_v<decltype(&Z::f),int(*)(Z::const&,int,int)>);// It allows us to specify the syntax for Z as a pass-by-value member functionstatic_assert(std::is_same_v<decltype(&Z::g),int(*)(Z::,int,int)>);

Such an approach unifies, to a degree, the member functions and the rest of the function type spaces, since it communicates not only that the first parameter is special, but also its type and calling convention.

2.6. Teachability Implications

Using auto&&thisself follows existing patterns for dealing with forwarding references.

Explicitly naming the object as the this-designated first parameter fits with many programmers' mental model of the this pointer being the first parameter to member functions "under the hood" and is comparable to usage in other languages, e.g. Python and Rust.

This also makes the definition of "const member function" more obvious, meaning it can more easily be taught to students.

It also works as a more obvious way to teach how std::bind and std::function work with a member function pointer by making the pointer explicit.

2.7. ABI implications for std::function and related

If references and pointers do not have the same representation for member functions, this effectively says "for the purposes of the this-designated first parameter, they do."

This matters because code written in the "this is a pointer" syntax with the this-> notation needs to be assembly-identical to code written with the self. notation; the two are just different ways to implement a function with the same signature.

2.8. virtual and this as value

Virtual member functions are always dispatched based on the type of the object the dot -- or arrow, in case of pointer -- operator is being used on. Once the member function is located, the parameter this is constructed with the appropriate move or copy constructor and passed as the this parameter, which might incur slicing.

Effectively, there is no change from current behavior -- only a slight addition of a new overload that behaves the way a user would expect.

Virtual member function templates are not allowed in the language today, and this paper does not propose a change from the current behavior for member functions with explicit object parameters either.

2.9. Can static member functions have a this parameter?

No. Static member functions currently do not have an implicit this parameter, and therefore have no reason to have an explicit one.

2.10. Interplays with capturing [this] and [*this] in lambdas

In the function parameter list, this just designates the explicit object parameter. It does not, in any way, change the meaning of this in the body of the lambda.

structX{intx,y;autogetter()const{return[*this](autoconst&this/* self */){returnx// still refers to X::x+this->y;// still refers to X::y};}};

If other language features play with what this means, they are completely orthogonal and do not have interplays with this proposal. However, it should be obvious that developers have great potential for introducing hard-to-read code if they are at all changing the meaning of this in function bodies, especially in conjunction with this proposal.

2.11. Translating code to use explicit object parameters

The most common qualifier overload sets for member functions are:

const and non-const

&, const&, &&, and const&&

const& and &&

Some examples:

1

2

3

structfoo{voidbar();voidbar()const;};

structfoo{voidbar()&;voidbar()const&;voidbar()&&;voidbar()const&&;};

structfoo{voidbar()const&;voidbar()&&;};

All three of these can be handled by a single perfect-forwarding overload, like this:

structfoo{template<classSelf>voidbar(Self&&thisself);};

This overload is callable for all const- and ref-qualified object parameters, just like the above examples. It is also callable for volatile-qualified objects, so the code is not entirely equivalent; however, the volatile versions are unlikely to be valid and more likely to be simply left out for the sake of brevity. The only major difference is in the third case, where non-const lvalue arguments would be non-const inside the function body, and const rvalue arguments would be const&& instead of const&. Again, this is unlikely to cause correctness issues unless this has other member functions called on it which do semantically different things depending on the cv-qualification of this.

2.12. Alternative syntax

Instead of qualifying the parameter with this, to mark it as the parameter for deducing this, we could let the first parameter be namedthis instead:

In the example above, this is no longer a pointer. Since this can never be a null pointer in valid code in the first place, this is an advantage, but may add confusion to the language. It also leaves us at a loss as to how one can address the derived object and the base object, as outlined in the previous section.

Rather than naming the first parameter this, we can also consider introducing a dummy template parameter where the qualifications normally reside. This syntax is also ill-formed today, and is purely a language extension:

template<typenameT>structX{Tvalue;// as proposedtemplate<typenameSelf>decltype(auto)foo(Self&&thisself){returnstd::forward<Self>(self).value;}// alternativetemplate<typenameThis>decltype(auto)foo()This&&{returnstd::forward<This>(*this).value;}// another alternativedecltype(auto)foo()auto&&{returnstd::forward<decltype(*this)>(*this).value;}};

This has the benefit of not muddying the parameter list, and it keeps the qualifier deduction off to the side where qualifiers usually live.

2.13. Unified Function Call Syntax

The proposed use of this as the first parameter seems as if these members functions really had better be written as non-members to begin with, and might suggest that the solution to this problem is really unified function call syntax (UFCS).

However, several of the motivating examples presented in this proposal are implementations of operators that cannot be implemented as non-members ((), [], ->, and unary *). UFCS alone would be insufficient. Additionally, the member function overload sets in all of these examples exist as member functions, not free functions, today. Having to take a member function overload set and rewrite it as a non-member (likely friended) free function template is very much changing the intended design of a class to overcome a language hurdle. This proposal contends that it would be more in keeping with programmer intent to allow member functions to stay member functions.

3. Real-World Examples

3.1. Deduplicating Code

This proposal can de-duplicate and de-quadruplicate a large amount of code. In each case, the single function is only slightly more complex than the initial two or four, which makes for a huge win. What follows are a few examples of how repeated code can be reduced.

The particular implementation of optional is Simon’s, and can be viewed on GitHub, and this example includes some functions that are proposed in P0798, with minor changes to better suit this format:

template<typenameT>classoptional{// ...template<typenameF>constexprautoand_then(F&&f)&{usingresult=invoke_result_t<F,T&>;static_assert(is_optional<result>::value,"F must return an optional");returnhas_value()?invoke(forward<F>(f),**this):nullopt;}template<typenameF>constexprautoand_then(F&&f)&&{usingresult=invoke_result_t<F,T&&>;static_assert(is_optional<result>::value,"F must return an optional");returnhas_value()?invoke(forward<F>(f),std::move(**this)):nullopt;}template<typenameF>constexprautoand_then(F&&f)const&{usingresult=invoke_result_t<F,constT&>;static_assert(is_optional<result>::value,"F must return an optional");returnhas_value()?invoke(forward<F>(f),**this):nullopt;}template<typenameF>constexprautoand_then(F&&f)const&&{usingresult=invoke_result_t<F,constT&&>;static_assert(is_optional<result>::value,"F must return an optional");returnhas_value()?invoke(forward<F>(f),std::move(**this)):nullopt;}// ...};

Keep in mind that there are a few more functions in P0798 that have this lead to this explosion of overloads, so the code difference and clarity is dramatic.

For those that dislike returning auto in these cases, it is very easy to write a metafunction that matches the appropriate qualifiers from a type. Certainly simpler than copying and pasting code and hoping that the minor changes were made correctly in every case.

3.2. Recursive Lambdas

This proposal also allows for an alternative solution to implementing a recursive lambda, since now we open up the possibility of allowing a lambda to reference itself:

// as proposed in [P0839]autofib=[]self(intn){if(n<2)returnn;returnself(n-1)+self(n-2);};// this proposalautofib=[](auto&thisself,intn){if(n<2)returnn;returnself(n-1)+self(n-2);};

This simply works following the established rules. The call operator of the closure object can have an explicit object parameter too, so self in this example is the closure object.

If the lambda would otherwise decay to a function pointer, &self shall have the value of that function pointer.

3.2.1. Expressions allowed for self in lambdas

self(...);// call with appropriate signaturedecltype(self);// evaluates to the type of the lambda with the appropriate// cv-ref qualifiers&self;// the address of either the closure object or function pointerstd::move(self)// you’re allowed to move yourself into an algorithm.../* ... and all other things you’re allowed to do with the lambda itself. */

Within lambda expressions, the this parameter still does not allow one to refer to the members of the closure object, which has no defined storage or layout, nor do its members have names. Instead it allows one to deduce the value category of the lambda and access its members -- including various call operators -- in the way appropriate for the value category.

3.2.2. Deducing derived objects for generic lambdas

When we deduce the object parameter, it doesn’t have to be the same type as the class - it could be a derived type. This isn’t typically relevant for lambdas, which would just be used as is, but it does provide an interesting opportunity when it comes to visitation. One tool to make it easier to invoke std::visit() on a std::variant is to write an overload utility which ends up creating a new type that inherits from all of the provided types. Consider a scenario where we have a Tree type which is a variant<Leaf,Node>, where a Node contains two sub-Trees. We could count the number of leaves in a Tree as follows:

In this example, self doesn’t deduce as that inner lambda, it deduces at the overload object, so this works.

3.3. CRTP, without the C, R, or even T

Today, a common design pattern is the Curiously Recurring Template Pattern. This implies passing the derived type as a template parameter to a base class template, as a way of achieving static polymorphism. If we wanted to just outsource implementing postfix incrementing to a base, we could use CRTP for that. But with explicit object parameters that deduce to the derived objects already, we don’t need any curious recurrence. We can just use standard inheritance and let deduction just do its thing. The base class doesn’t even need to be a template:

3.4. SFINAE-friendly callables

A seemingly unrelated problem to the question of code quadruplication is that of writing these numerous overloads for function wrappers, as demonstrated in P0826. Consider what happens if we implement std::not_fn(), as currently specified:

template<typenameF>classcall_wrapper{Ff;public:// ...template<typename...Args>autooperator()(Args&&...)&->decltype(!declval<invoke_result_t<F&,Args...>>());template<typename...Args>autooperator()(Args&&...)const&->decltype(!declval<invoke_result_t<constF&,Args...>>());// ... same for && and const && ...};template<typenameF>autonot_fn(F&&f){returncall_wrapper<std::decay_t<F>>{std::forward<F>(f)};}

As described in the paper, this implementation has two pathological cases: one in which the callable is SFINAE-unfriendly (which would cause a call to be ill-formed, when it could otherwise work), and one in which overload is deleted (which would cause a call to fallback to a different overload, when it should fail):

structunfriendly{template<typenameT>autooperator()(Tv){static_assert(std::is_same_v<T,int>);returnv;}template<typenameT>autooperator()(Tv)const{static_assert(std::is_same_v<T,double>);returnv;}};structfun{template<typename...Args>voidoperator()(Args&&...)=delete;template<typename...Args>booloperator()(Args&&...)const{return true;}};std::not_fn(unfriendly{})(1);// static assert!// even though the non-const overload is viable and would be the best// match, during overload resolution, both overloads of unfriendly have// to be instantiated - and the second one is a hard compile error.std::not_fn(fun{})();// ok!? Returns false// even though we want the non-const overload to be deleted, the const// overload of the call_wrapper ends up being viable - and the only viable// candidate.

Gracefully handling SFINAE-unfriendly callables is not solvable in C++ today. Preventing fallback can be solved by the addition of yet another four overloads, so that each of the four cv/ref-qualifiers leads to a pair of overloads: one enabled and one deleted.

This proposal solves both problems by simply allowing this to be deduced. The following is a complete implementation of std::not_fn:

Here, there is only one overload with everything deduced together. The first example now works correctly. Self gets deduced as call_wrapper<unfriendly>, and the one operator() will only consider unfriendly's non-const call operator. The const one is simply never considered, so does not have an opportunity to cause problems. The call works.

The second example now fails correctly. Previously, we had four candidates: the two non-const ones were removed from the overload set due to fun's non-const call operator being deleted, and the two const ones which were viable. But now, we only have one candidate. Self gets deduced as call_wrapper<fun>, which requires fun's non-const call operator to be well-formed. Since it is not, the call is an error. There is no opportunity for fallback since there is only one overload ever considered.

As a result, this singular overload then has precisely the desired behavior: working, for unfriendly, and not working, for fun.

4. Acknowledgements

The authors would like to thank:

Jonathan Wakely, for bringing us all together by pointing out we were writing the same paper, twice