Date: Fri, 11 Aug 2023 11:28:47 +0200
@Jason:
> I already outlined the fundamental misunderstanding prevalent in your coroutine design. We shouldn't add a feature for allowing people to couple things that don't need coupling.
How can you know what needs coupling and what doesn't from the programmer's point of view?
But anyway, my proposal somehow addresses the exact opposite: I try to point out that the current coroutine design does couple some things together for actual no reason and I try to show a possible solution on how to unravel that.
> C++ already covers this, as the first parameter for any member function in the lookup is always `*this`. Naturally C++23 continues with this with explicit object parameter functions.
Currently, that does _not_ help with promise c-tors, see that code example:
struct my_class
{
struct ret
{
struct promise_type
{
promise_type(my_class* p_class_instance, int value) { /* ... */ }
/* .... */
};
};
// ERROR: this will _not_ compile, because the "this" pointer is _not_ passed
// on to the promise c-tor, thus the promise c-tor signature doesn't match
// the coroutine signature.
ret my_member_coroutine(int value)
{
/* ... */
co_await /* .... */;
}
}
(Note: the only way of passing the "this" pointer here to the coroutine is by wrapping it by another member function of the class that in turn calls the coroutine passing "this" as an additional parameter. For me, that looks like another ugly workaround showing a limitation of the current design.)
> Can you give an example where this is useful, using a design that actually works the way coroutines are meant to work?
I already tried to show a valid use case for coroutines that the initial designers obviously hadn't in mind. From your point of view, this is of course _not_ the way they are meant to work, because otherwise the initial design would already have covered that use case.
But I think I will anyway try to meld down all your counter-arguments into a new revision of my proposal as soon as I find some time. You already helped me to see more clearly the actual point of my proposal.
Greetings
Stefan
> I already outlined the fundamental misunderstanding prevalent in your coroutine design. We shouldn't add a feature for allowing people to couple things that don't need coupling.
How can you know what needs coupling and what doesn't from the programmer's point of view?
But anyway, my proposal somehow addresses the exact opposite: I try to point out that the current coroutine design does couple some things together for actual no reason and I try to show a possible solution on how to unravel that.
> C++ already covers this, as the first parameter for any member function in the lookup is always `*this`. Naturally C++23 continues with this with explicit object parameter functions.
Currently, that does _not_ help with promise c-tors, see that code example:
struct my_class
{
struct ret
{
struct promise_type
{
promise_type(my_class* p_class_instance, int value) { /* ... */ }
/* .... */
};
};
// ERROR: this will _not_ compile, because the "this" pointer is _not_ passed
// on to the promise c-tor, thus the promise c-tor signature doesn't match
// the coroutine signature.
ret my_member_coroutine(int value)
{
/* ... */
co_await /* .... */;
}
}
(Note: the only way of passing the "this" pointer here to the coroutine is by wrapping it by another member function of the class that in turn calls the coroutine passing "this" as an additional parameter. For me, that looks like another ugly workaround showing a limitation of the current design.)
> Can you give an example where this is useful, using a design that actually works the way coroutines are meant to work?
I already tried to show a valid use case for coroutines that the initial designers obviously hadn't in mind. From your point of view, this is of course _not_ the way they are meant to work, because otherwise the initial design would already have covered that use case.
But I think I will anyway try to meld down all your counter-arguments into a new revision of my proposal as soon as I find some time. You already helped me to see more clearly the actual point of my proposal.
Greetings
Stefan
Received on 2023-08-11 09:28:50