Repository navigation
can a sender's connect member fn be private if it befriends execution::connect_t? #342
Description
can a user expect this to work?
#include <execution>
struct Sender
{
using sender_concept = std::execution::sender_t;
private:
friend std::execution::connect_t;
auto connect( std::execution::receiver auto rcvr )
{
//...
}
};
int main()
{
auto op = std::execution::connect(Sender{}, SomeReceiver{});
}the current wording suggests it should work but it is not guaranteed. should it be?
same question about get_env and get_completion_signatures — although the latter is complicated by the fact that there is no get_completion_signatures_t to befriend.
Activity
dietmarkuehl commentedon Jul 3, 2025
I have implemented various members as
privatemaking the CPO a friend: that is akin makingvirtualfunctionsprotectedand forwarding from apublic(inline) function. That is very useful when adding instrumentation which should apply to all uses of a customization.The real question is, in my mind the opposite one: should a user be allowed to write
Sender{}.connect(SomeReceiver{})? …and I think the answer should be “no!” This also applies tostart,set_value, etc.ericniebler commentedon Jul 3, 2025
i agree this is a better framing. of course, of
Senderis a type they control, then we can't tell people to not callconnectdirectly on it. but we can say that ifSenderis library-provided, they cannot.a related question is whether we want to allow
execution::connectto, say, wrap the returned operation state for some reason. in which case,connect(sndr, rcvr)would not be equivalent tosndr.connect(rcvr).ispeters commentedon Jul 4, 2025
That (
connectwrappingsndr.connect(rcvr)) is how Unifex implements async stacks so I think that should be left open as an implementation option.lewissbaker commentedon Jul 4, 2025
It is already the case that
connect(sndr, rcvr)may not be the same assndr.connect(rcvr)becauseconnect(sndr, rcvr)appliestransform_sender(sndr, get_env(rcvr))before then trying to call.connect(rcvr)member function.