This PR contains editorial fixes relating to coroutine_handle's from_address method ([coroutine.handle.import.export]). It is related to #5.
Consolidate duplicate definitions of
There are currently two definitions of the from_address: one in [coroutine.handle.import.export] and one in [coroutine.handle.import]. In the class synopses in [coroutine.handle], the coroutine_handle<> specialization references [coroutine.handle.import.export] while primary definition for coroutine_handle references [corouinte.handle.import].
They are nearly identical in wording. although the definition in [coroutine.handle.import.export] is written as if it was out of line (e.g. coroutine_handle<>::from_address).
Even though the primary template of coroutine_handle inherits from coroutine_handle<> it is necessary to define from_address in the primary template, but I did not realize this at first. from_address returns coroutine_handle, which is a different type in the primary template than it is in coroutine_handle (we use coroutine_handle within the class definition so this may not be clear at first to consumers of the spec):
template <typename T>
struct A;
template <>
struct A<void> { static A make_A() { return A{}; } };
template <typename T>
struct A : A<void> { };
int main()
{
A<void> a = A<void>::make_A(); // OK
A<int> a = A<int>::make_A(); // ERROR: Conflicting declarations.
}
Otherwise, the two definitions are identical.
I think the best thing to do is to keep the declarations in both classes in the class synopsis and have one definition of from_address, but list both signatures as if they were out of line, e.g.:
Replace address() with address in precondition wording
from_address's Requires: paragraph in [coroutine.handle.import.export] states the pre-condition that "addr was obtained via a prior call to address()". It should be address, not address(), since address() is an expression not a method (e.g. read very pedantically, this says "obtained via a prior call to some void*" which doesn't make sense).
Add missing constexpr
from_address is declared constexpr in the class synopsis ([coroutine.handle], in both the primary template and the specialization for coroutine_handle<>) but is not constexpr in the definition. The design intent, I believe, is for from_address to be constexpr.
This pull request:
Deletes the odd from_address definition containing coroutine_handle<>:from_address in [coroutine.handle.import.export].
Moves the from_address definition from [coroutine.handle.import] to [coroutine.handle.import.export].
Deletes the section [coroutine.handle.import].
Updates references to [coroutine.handle.import] to point to [coroutine.handle.import.export].
List both the coroutine_handle<> and coroutine_handle<Promise> signature in the new unified definition of from_address.
Replaces address() with address in from_address's precondition wording [coroutine.handle.import.export] p2.
Make the from_address signature in [coroutine.handle.import.export] constexpr.
This PR contains editorial fixes relating to
coroutine_handle
'sfrom_address
method ([coroutine.handle.import.export]). It is related to #5.Consolidate duplicate definitions of
There are currently two definitions of the
from_address
: one in [coroutine.handle.import.export] and one in [coroutine.handle.import]. In the class synopses in [coroutine.handle], thecoroutine_handle<>
specialization references [coroutine.handle.import.export] while primary definition forcoroutine_handle
references [corouinte.handle.import].They are nearly identical in wording. although the definition in [coroutine.handle.import.export] is written as if it was out of line (e.g.
coroutine_handle<>::from_address
).Even though the primary template of
coroutine_handle
inherits fromcoroutine_handle<>
it is necessary to definefrom_address
in the primary template, but I did not realize this at first.from_address
returnscoroutine_handle
, which is a different type in the primary template than it is incoroutine_handle
(we usecoroutine_handle
within the class definition so this may not be clear at first to consumers of the spec):Otherwise, the two definitions are identical.
I think the best thing to do is to keep the declarations in both classes in the class synopsis and have one definition of
from_address
, but list both signatures as if they were out of line, e.g.:Replace
address()
withaddress
in precondition wordingfrom_address
's Requires: paragraph in [coroutine.handle.import.export] states the pre-condition that "addr
was obtained via a prior call toaddress()
". It should beaddress
, notaddress()
, sinceaddress()
is an expression not a method (e.g. read very pedantically, this says "obtained via a prior call to somevoid*
" which doesn't make sense).Add missing constexpr
from_address
is declaredconstexpr
in the class synopsis ([coroutine.handle], in both the primary template and the specialization forcoroutine_handle<>
) but is notconstexpr
in the definition. The design intent, I believe, is forfrom_address
to be constexpr.This pull request:
from_address
definition containingcoroutine_handle<>:from_address
in [coroutine.handle.import.export].from_address
definition from [coroutine.handle.import] to [coroutine.handle.import.export].coroutine_handle<>
andcoroutine_handle<Promise>
signature in the new unified definition offrom_address
.address()
withaddress
infrom_address
's precondition wording [coroutine.handle.import.export] p2.from_address
signature in [coroutine.handle.import.export]constexpr
.