So far, all of our coroutine promises have had only a default constructor. But the standard actually gives the promise access to the coroutine parameters, if it wants them.\u00b9<\/p>\n
If somebody declares a coroutine that uses your promise, say,<\/p>\n
simple_task<void> Awesome(int x, int y)\r\n{\r\n ...\r\n}\r\n<\/pre>\nthe compiler first looks for a promise constructor that accepts those parameters, prefixed if applicable by the hidden *this<\/code> parameter. In this example, it tries to construct a simple_promise(x, y)<\/code>. Standard overload rules apply, so the actual constructor could take two integer lvalues, or one integer lvalue and one integer by value, or maybe it takes two long<\/code>s, since integers are implicitly convertible to long<\/code>. This gives your coroutine an opportunity to snoop on the parameters. For example, you might have a promise that detects that one of the parameters is a Logger<\/code>, in which case it uses that logging object for its own internal logging.<\/p>\nIf no suitable constructor can be found, then the compiler falls back to using the default constructor for the promise.<\/p>\n
You might say, “Well, that’s interesting, but it has no effect on me because my only constructor is the default constructor, so that’s the only one the compiler will ever use.”<\/p>\n
You’d be wrong.<\/p>\n
Because the compiler will autogenerate a copy constructor.<\/p>\n
Somebody could create a coroutine like this:<\/p>\n
simple_task<void> Weirdo(simple_promise<void> wha)\r\n{\r\n ...\r\n}\r\n<\/pre>\nIf they do that, then the compiler will look for a promise constructor that takes a simple_promise<void><\/code> parameter, and it will find one: The copy constructor. The promise for the coroutine will therefore be copy-constructed<\/i> from the wha<\/code> parameter, which is probably not what you were expecting.<\/p>\nOn the other hand, the fact that they are passing your private promise type as a parameter suggests that they are intentionally messing with the internals and therefore deserve what they get.<\/p>\n
However, an unwitting developer might stumble into this case if they create a generic type similar to std::any<\/code>:<\/p>\nstruct Object\r\n{\r\n template<typename T>\r\n operator T() { return std::any_cast<T>(o); }\r\n\r\n template<typename T>\r\n Object& operator=(T&& other)\r\n { o = std::forward<T>(other); return *this; }\r\n\r\nprivate:\r\n std::any o;\r\n};\r\n<\/pre>\nThis is a generic type that can hold any value, and you can get the same value out by converting to the thing you hope is inside.<\/p>\n
Which means that it can try to convert to simple_promise<\/code>.<\/p>\nsimple_task<void> Print(Object o)\r\n{\r\n ...\r\n}\r\n<\/pre>\nThe compiler will see that an Object<\/code> can be passed to the simple_Object<\/code> to a simple_std::Object<\/code> to a simple_Let’s fix that by explicitly denying copying.<\/p>\n
template<typename T>\r\n struct simple_promise_base\r\n {\r\n ...\r\n\r\n simple_promise_base() = default;\r\n simple_promise_base(simple_promise_base const&) = delete;\r\n void operator=(simple_promise_base const&) = delete;<\/span>\r\n\r\n ...\r\n };\r\n<\/pre>\nI’m going to declare this the nominal end of what turned into a 47-part series on coroutines,\u00b2 because I’m pretty sure you’re all sick of coroutines by now. There are still some other topics related to coroutines that aren’t connected to this series, so you’re not out of the woods yet. And there’s generators, which is deserving of its own series, but I’ll wait until the outrage dies down.<\/p>\n
\u00b9 Be aware that this is a dark corner of the language specification that not all implementations agree on. The specification says that the parameters are passed as lvalues, but gcc passes them as their original reference class, and MSVC doesn’t pass them at all until you upgrade to version 16.8 or higher<\/a>, set \/std:c++latest<\/code>, and omit the legacy \/await<\/code> flag.<\/p>\n