{"id":102354,"date":"2019-03-22T07:00:00","date_gmt":"2019-03-22T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102354"},"modified":"2019-05-07T06:44:40","modified_gmt":"2019-05-07T13:44:40","slug":"20190322-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190322-00\/?p=102354","title":{"rendered":"Turning anything into a fire-and-forget coroutine"},"content":{"rendered":"

Last time<\/a>, we wrote a helper function for converting an awaitable into a winrt::<\/code>fire_<\/code>and_<\/code>forget<\/code>, as well as another helper function that takes a lambda that returns<\/i> an awaitable, and which invokes the lambmda as a winrt::<\/code>fire_<\/code>and_<\/code>forget<\/code>. <\/p>\n

After I wrote the two functions, I wondered if I could unify them. Mostly because I wanted to use the same name no_await<\/code> for both functions. <\/p>\n

This took me down the horrible rabbit hole known as C++ template metaprogramming. I wanted two versions of the function, one that is used if the parameter is awaitable, and another that is used if the parameter is a functor. This led me to try using things like std::<\/code>enable_<\/code>if<\/code> to detect which case I’m in, and that led to lots of frustration, especially because there’s no easy way to detect if a type is awaitable. My closest approach was <\/p>\n

\ntemplate<typename T, typename Promise = std::void_t<>>\nstruct is_awaitable : std::false_type {};\n\ntemplate<typename T>\nstruct is_awaitable<T, std::void_t<typename std::experimental::coroutine_traits<T>::promise_type>> : std::true_type {};\n\ntemplate<typename T>\ninline constexpr bool is_awaitable_v = is_awaitable<T>::value;\n<\/pre>\n
which infers that a type is awaitable by sniffing whether it has an associated promise_<\/code>type<\/code>. This isn’t foolproof, because some types like winrt::<\/code>fire_<\/code>and_<\/code>forget<\/code> have a promise_<\/code>type<\/code> that cannot be awaited. <\/p>\n
My first realization was that I could flip the test. Instead of checking whether the argument is awaitable, I check whether it is invokable. <\/p>\n
\ntemplate<typename T>\nfire_and_forget no_await(T t)\n{\n    if constexpr (std::is_invocable_v<T>)\n    {\n        co_await t();\n    }\n    else\n    {\n        co_await t;\n    }\n}\n<\/pre>\n
Now you can use no_<\/code>await<\/code> with awaitables or functors that return awaitables. <\/p>\n
\nvoid Stuff()\n{\n  \/\/ Start this operation but don't wait for it to finish\n  no_await(DoSomethingAsync());\n\n  \/\/ Start this sequence of things and don't wait for\n  \/\/ them to finish.\n  no_await([=]() -> IAsyncAction\n  {\n    co_await Step1Async();\n    \/\/ Step 2 doesn't start until Step 1 completes.\n    co_await Step2Async();\n  });\n}\n<\/pre>\n
On the other hand, for the case of the lambda passed to no_<\/code>await<\/cODE>, you could just declare your lambda as returning a winrt::<\/code>fire_<\/code>and_<\/code>forget<\/code>, and then you wouldn't need no_<\/code>await<\/code>. <\/p>\n
\nvoid Stuff()\n{\n  \/\/ Start this operation but don't wait for it to finish\n  no_await(DoSomethingAsync());\n\n  \/\/ Start this sequence of things and don't wait for\n  \/\/ them to finish.\n  invoke_async_lambda([=]() -> winrt::fire_and_forget\n  {\n    co_await Step1Async();\n    \/\/ Step 2 doesn't start until Step 1 completes.\n    co_await Step2Async();\n  });\n}\n<\/pre>\n
But I like the fact that the first example uniformly uses the name no_<\/code>await<\/code> to describe the concept of \"I'm not going to wait for this thing to finish.\" And also I'm perhaps unduly attached to the cute name. <\/p>\n","protected":false},"excerpt":{"rendered":"
Turning on the metaprogramming.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-102354","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Turning on the metaprogramming.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=102354"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102354\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=102354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
My second realization was that I didn’t have to do fancy template metaprogramming at all. I could take advantage of the new if constexpr<\/code> feature<\/a>. <\/p>\n