In the paper about resumable functions, in the section about restrictions three restrictions are listed:
- Resumable functions cannot use a variable number of arguments. For situations where varargs are necessary,the argument unwrapping may be placed in a function that calls a resumable function after doing the unwrapping of arguments.
- The return type of a resumable function must be
future<T>
or shared_future<T>
. The restrictions on T are defined by std::future
, not this proposal, but T
must be a copyable or movable type, or ‘void
’. It must also be possible to construct a variable of T
without an argument; that is, it has to have an accessible (implicit or explicit) default constructor if it is of a class type.
- Await expressions may not appear within the body of an exception handler and should not be executed while a lock on any kind is being held by the executing thread.
There must be a reason behind this restrictions and due to my lack of knowledge about concurrency I cannot deduce what reasons are. Could someone enlight me about this topic?
Variable number of arguments
This restriction is referring to the C-style variadic functions or the C++11 variadic template ones?
- If is the C-style ones, the reason of the limitation is related to the magic trickery done by the
va_*
macros?
- If is referring to the variadric template functions I assume that the limitation must be related with the unpacking of the parameter pack not with the fact that the function is a template one (there's no wording about template resumable functions, so I assume that they're legal).
In both cases, I thought that the compiler could be smart enough to deduce which function to use.
Default constructible and copyable/movable type
I understand the reason behind returning a std::future
or std::shared_future
, but I'm guessing that the reason of the limitation behind the usable types is related to the types that the futures could use.
So, the paper is proposing to extend the language with two new keywords (resumable and await) that provides the behaviour of resumable functions but in the end it trust on existent constructs to transfer the return values of resumable functions between the function and the caller.
Why not propose some kind of language extension for the return values too? that could (maybe) release the limitation to default constructible and copyable/movable types and fix the assimetry between the return type and the returned type:
It should thus be noted that there is an asymmetry between the function’s observed behavior from the outside (caller) and the inside: the outside perspective is that function returns a value of type future<T>
at the first suspension point, while the inside perspective is that the function returns a value of type T
via a return statement (...)
No awaitable exception handlers nor awaitable locked threads
I guess that awaiting something while catching an exception have no sense, but I haven't any clue about the limitation of the locked threads.