{"id":30707,"date":"2022-06-27T10:41:41","date_gmt":"2022-06-27T10:41:41","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=30707"},"modified":"2022-06-27T16:58:17","modified_gmt":"2022-06-27T16:58:17","slug":"cpp23-deducing-this","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/cpp23-deducing-this\/","title":{"rendered":"C++23’s Deducing this: what it is, why it is, how to use it"},"content":{"rendered":"

Deducing this<\/code><\/a> (P0847) is a C++23 feature which gives a new way of specifying non-static member functions. Usually when we call an object’s member function, the object is implicitly<\/em> passed to the member function, despite not being present in the parameter list. P0847 allows us to make this parameter explicit<\/em>, giving it a name and const<\/code>\/reference qualifiers. For example:<\/p>\n

struct implicit_style {\r\n    void do_something(); \/\/object is implicit\r\n};\r\n\r\nstruct explicit_style {\r\n    void do_something(this explicit_style& self); \/\/object is explicit\r\n};<\/code><\/pre>\n
The explicit object parameter is distinguished by the keyword this<\/code> placed before the type specifier, and is only valid for the first parameter of the function.<\/p>\n
The reasons for allowing this may not seem immediately obvious, but a bunch of additional features fall out of this almost by magic. These include de-quadruplication of code, recursive lambdas, passing this<\/code> by value, and a version of the CRTP<\/a> which doesn’t require the base class to be templated on the derived class.<\/p>\n
This post will walk through an overview of the design, then many of the cases you can use this feature for in your own code.<\/p>\n
For the rest of this blog post I’ll refer to the feature as “explicit object parameters”, as it makes more sense as a feature name than “deducing this<\/code>“. Explicit object parameters are supported in MSVC as of Visual Studio 2022 version 17.2. A good companion to this post is Ben Deane’s talk Deducing this<\/code> Patterns<\/a> from CppCon.<\/p>\n
Overview<\/h2>\n
The paper which proposed this feature was written by Ga\u0161per A\u017eman<\/a>, Ben Deane<\/a>, Barry Revzin<\/a>, and myself<\/a>, and was guided by the experience of many experts in the field<\/a>. Barry and I began writing a version of this paper after we each implemented std::optional<\/code><\/a> and came across the same problem. We would be writing the value<\/code> function of optional<\/code> and, like good library developers, we’d try to make it usable and performant in as many use-cases as we could. So we’d want value<\/code> to return a const<\/code> reference if the object it was called on was const<\/code>, we’d want it to return an rvalue if the object it was called on was an rvalue, etc. It ended up looking like this:<\/p>\n
template <typename T>\r\nclass optional {\r\n  \/\/ version of value for non-const lvalues\r\n  constexpr T& value() & {\r\n    if (has_value()) {\r\n      return this->m_value;\r\n    }\r\n    throw bad_optional_access();\r\n  }\r\n\r\n  \/\/ version of value for const lvalues\r\n  constexpr T const& value() const& {\r\n    if (has_value()) {\r\n      return this->m_value;\r\n    }\r\n    throw bad_optional_access();\r\n  }\r\n\r\n  \/\/ version of value for non-const rvalues... are you bored yet?\r\n  constexpr T&& value() && {\r\n    if (has_value()) {\r\n      return std::move(this->m_value);\r\n    }\r\n    throw bad_optional_access();\r\n  }\r\n\r\n  \/\/ you sure are by this point\r\n  constexpr T const&& value() const&& {\r\n    if (has_value()) {\r\n      return std::move(this->m_value);\r\n    }\r\n    throw bad_optional_access();\r\n  }\r\n  \/\/ ...\r\n};<\/code><\/pre>\n
(If you’re not familiar with the member_function_name() &<\/code> syntax, this is called “ref-qualifiers” and you can find more info on Andrzej Krzemie\u0144ski’s blog<\/a>. If you’re not familiar with rvalue references (T&&<\/code>) you can read up on move semantics on this Stack Overflow question<\/a>)<\/p>\n
Note the near-identical implementations of four versions of the same function, only differentiated on whether they’re const<\/code> and whether they move the stored value instead of copying it.<\/p>\n
Barry and I would then move on to some other function and have to do the same thing. And again and again, over and over, duplicating code, making mistakes, building maintenance headaches for the future versions of ourselves. “What if”, we thought, “you could just write this?”<\/p>\n
template <typename T>\r\nstruct optional {\r\n  \/\/ One version of value which works for everything\r\n  template <class Self>\r\n  constexpr auto&& value(this Self&& self) {\r\n    if (self.has_value()) {\r\n        return std::forward<Self>(self).m_value;\r\n    }\r\n    throw bad_optional_access();\r\n  }<\/code><\/pre>\n
(If you’re not familiar with std::forward<\/code>, you can read about perfect forwarding on Eli Bendersky’s blog<\/a>)<\/p>\n
This does the same thing as the above four overloads, but in a single function. Instead of writing different versions of value<\/code> for const optional&<\/code>, const optional&&<\/code>, optional&<\/code>, and optional&&<\/code>, we write one function template which deduces<\/em> the const<\/code>\/volatile<\/code>\/reference (cvref for short) qualifiers of the object the it is called on. Making this change for almost every function in the type would cut down our code by a huge amount.<\/p>\n
So we wrote a version of what eventually got standardised, soon discovered that Ga\u0161per and Ben were working on a different paper for the exact same feature, we joined forces, and here we all are several years later.<\/p>\n
Design<\/h3>\n
The key design principle we followed was that it should do what you expect<\/em>. To achieve this, we touched as few places in the standard as we possibly could. Notably, we didn’t touch overload resolution rules or template deduction rules, and name resolution was only changed a little bit (as a treat).<\/p>\n
As such, say we have a type like so:<\/p>\n
struct cat {\r\n    template <class Self>\r\n    void lick_paw(this Self&& self);\r\n};<\/code><\/pre>\n
The template parameter Self<\/code> will be deduced based on all of the same template deduction rules you’re already familiar with. There’s no additional magic. You don’t have to use the names Self<\/code> and self<\/code>, but I think they’re the clearest options, and this follows what several other programming languages do.<\/p>\n
cat marshmallow;\r\nmarshmallow.lick_paw();                         \/\/Self = cat&\r\n\r\nconst cat marshmallow_but_stubborn;\r\nmarshmallow_but_stubborn.lick_paw();            \/\/Self = const cat&\r\n\r\nstd::move(marshmallow).lick_paw();              \/\/Self = cat\r\nstd::move(marshmallow_but_stubborn).lick_paw(); \/\/Self = const cat<\/code><\/pre>\n
One name resolution change is that inside such a member function, you are not allowed to explicitly or implicitly refer to this<\/code>.<\/p>\n
struct cat {\r\n    std::string name;\r\n\r\n    void print_name(this const cat& self) {\r\n        std::cout << name;       \/\/invalid\r\n        std::cout << this->name; \/\/also invalid\r\n        std::cout << self.name;  \/\/all good\r\n    }\r\n};<\/code><\/pre>\n
Use Cases<\/h2>\n
For the rest of this post, we’ll look at all the different uses of this feature (at least the ones discovered so far that I know of!) Many of these examples were taken straight from the paper.<\/p>\n
De-duplication\/quadruplication<\/h3>\n
We’ve already seen how the feature can be applied to a type such as optional<\/code> to avoid having to write four overloads of the same function.<\/p>\n
Note also that this lowers the burden on initial implementation and maintenance of dealing with rvalue member functions. Quite often developers will write only const<\/code> and non-const<\/code> overloads for member functions, since in many cases we don’t really want to write another two whole functions just to deal with rvalues. With deduced qualifiers on this<\/code>, we get the rvalue versions for free: we just need to write std::forward<\/code> in the right places to get the runtime performance gains which come with avoiding unnecessary copies:<\/p>\n
class cat {\r\n    toy held_toy_;\r\n\r\npublic:\r\n    \/\/Before explicit object parameters\r\n    toy& get_held_toy() { return held_toy_; }\r\n    const toy& get_held_toy() const { return held_toy_; }\r\n\r\n    \/\/After\r\n    template <class Self>\r\n    auto&& get_held_toy(this Self&& self) {\r\n        return self.held_toy_;\r\n    }\r\n\r\n    \/\/After + forwarding\r\n    template <class Self>\r\n    auto&& get_held_toy(this Self&& self) {\r\n        return std::forward<Self>(self).held_toy_;\r\n    }\r\n};<\/code><\/pre>\n
Of course for a simple getter like this, whether or not this change is worth it for your specific use case is up to you. But for more complex functions, or cases where you are dealing with large objects which you want to avoid copying, explicit object parameters make this much easier to handle.<\/p>\n
CRTP<\/h3>\n
The Curiously Recurring Template Pattern (CRTP) is a form of compile-time polymorphism which allows you to extend types with common pieces of functionality without paying the runtime costs of virtual functions. This is sometimes referred to as mixins<\/em> (this isn’t all<\/em> the CRTP can be used for, but it is the most common use). For example, we could write a type add_postfix_increment<\/code> which can be mixed in to another type in order to define postfix increment in terms of prefix increment:<\/p>\n
template <typename Derived>\r\nstruct add_postfix_increment {\r\n    Derived operator++(int) {\r\n        auto& self = static_cast<Derived&>(*this);\r\n\r\n        Derived tmp(self);\r\n        ++self;\r\n        return tmp;\r\n    }\r\n};\r\n\r\nstruct some_type : add_postfix_increment<some_type> {\r\n    \/\/ Prefix increment, which the postfix one is implemented in terms of\r\n    some_type& operator++();\r\n};<\/code><\/pre>\n
Templating a base class on its derived cast and static_cast<\/code>ing this<\/code> inside the function can be a bit arcane, and the problem gets worse when you have multiple levels of CRTP. With explicit object parameters, since we didn’t change template deduction rules, the type of the explicit object parameter can be deduced to a derived type<\/em>. More concretely:<\/p>\n
struct base {\r\n    template <class Self>\r\n    void f(this Self&& self);\r\n};\r\n\r\nstruct derived : base {};\r\n\r\nint main() {\r\n    derived my_derived;\r\n    my_derived.f();\r\n}<\/code><\/pre>\n
In the call my_derived.f()<\/code>, the type of Self<\/code> inside f<\/code> is derived&<\/code>, not<\/em> base&<\/code>.<\/p>\n
This means that we can define the above CRTP example like so:<\/p>\n
struct add_postfix_increment {\r\n    template <typename Self>\r\n    auto operator++(this Self&& self, int) {\r\n        auto tmp = self;\r\n        ++self;\r\n        return tmp;\r\n    }\r\n};\r\n\r\nstruct some_type : add_postfix_increment {\r\n    \/\/ Prefix increment, which the postfix one is implemented in terms of\r\n    some_type& operator++();\r\n};<\/code><\/pre>\n
Note that now add_postfix_increment<\/code> is not a template. Instead, we’ve moved the customisation to the postfix operator++<\/code>. This means we don’t need to pass some_type<\/code> as a template argument anywhere: everything “just works”.<\/p>\n
Forwarding out of lambdas<\/h3>\n
Copying captured values out of a closure is simple: we can just pass around the object as usual. Moving captured values out of a closure is also simple: we can just call std::move<\/code> on it. A problem occurs when we need to perfect-forward a captured value based on whether the closure is an lvalue or rvalue.<\/p>\n
One use case I stole from P2445<\/a> is for lambdas which can be used in both “retry” and “try or fail” contexts:<\/p>\n
auto callback = [m=get_message(), &scheduler]() -> bool {\r\n    return scheduler.submit(m);\r\n};\r\ncallback(); \/\/ retry(callback)\r\nstd::move(callback)(); \/\/ try-or-fail(rvalue)<\/code><\/pre>\n
The question here is: how do we forward m<\/code> based on the value category of the closure? Explicit object parameters give us the answer. Since a lambda generates a class with an operator()<\/code> member function of the given signature, all the machinary I’ve just explained works for lambdas too.<\/p>\n
auto closure = [](this auto&& self) {\r\n    \/\/can use self inside the lambda\r\n};<\/code><\/pre>\n
This means we can perfect-forward based on the value category of the closure inside the lambda. P2445 gives a std::forward_like<\/code> helper, which forwards some expression based on the value category of another:<\/p>\n
auto callback = [m=get_message(), &scheduler](this auto &&self) -> bool {\r\n    return scheduler.submit(std::forward_like<decltype(self)>(m));\r\n};<\/code><\/pre>\n
Now our original use case works, and the captured object will be copied or moved depending on how we use the closure.<\/p>\n
Recursive lambdas<\/h3>\n
Since we now have the ability to name the closure object in a lambda’s parameter list, this allows us to do recursive lambdas! As above:<\/p>\n
auto closure = [](this auto&& self) {\r\n    self(); \/\/just call ourself until the stack overflows\r\n};<\/code><\/pre>\n
There are more useful uses for this than just overflowing stacks, though. Consider, for example, the ability to do visitation of recursive data structures without having to define additional types or functions? Given the following definition of a binary tree:<\/p>\n
struct Leaf { };\r\nstruct Node;\r\nusing Tree = std::variant<Leaf, Node*>;\r\nstruct Node {\r\n    Tree left;\r\n    Tree right;\r\n};<\/code><\/pre>\n
We can count the number of leaves like so:<\/p>\n
int num_leaves(Tree const& tree) {\r\n    return std::visit(overload( \/\/see below\r\n        [](Leaf const&) { return 1; },                       \r\n        [](this auto const& self, Node* n) -> int {              \r\n            return std::visit(self, n->left) + std::visit(self, n->right); \r\n        }\r\n    ), tree);\r\n}<\/code><\/pre>\n
overload<\/code> here is some facility to create an overload set from multiple lambdas, and is commonly used for variant<\/code> visitation. See cppreference<\/a>, for example.<\/p>\n
This counts the number of leaves in the tree through recursion. For each function call in the call graph, if the current is a Leaf<\/code>, it returns 1<\/code>. Otherwise, the overloaded closure calls itself through self<\/code> and recurses, adding together the leaf counts for the left and right subtrees.<\/p>\n
Pass this<\/code> by value<\/h3>\n
Since we can define the qualifiers of the now-explicit object parameter, we can choose to take it by value rather than by reference. For small objects, this can give us better runtime performance. In case you’re not familiar with how this affects code generation, here’s an example.<\/p>\n
Say we have this code, using regular old implicit object parameters:<\/p>\n
struct just_a_little_guy {\r\n    int how_smol;\r\n    int uwu();\r\n};\r\n\r\nint main() {\r\n    just_a_little_guy tiny_tim{42};\r\n    return tiny_tim.uwu();\r\n}<\/code><\/pre>\n
MSVC generates the following assembly:<\/p>\n
sub     rsp, 40                           \r\nlea     rcx, QWORD PTR tiny_tim$[rsp]\r\nmov     DWORD PTR tiny_tim$[rsp], 42     \r\ncall    int just_a_little_guy::uwu(void)  \r\nadd     rsp, 40                            \r\nret     0<\/code><\/pre>\n
I’ll walk through this line-by-line.<\/p>\n