can a sender's `connect` member fn be private if it befriends `execution::connect_t`?

[ericniebler]

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.

[dietmarkuehl]

I have implemented various members as private making the CPO a friend: that is akin making virtual functions protected and forwarding from a public (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 to start, set_value, etc.

[ericniebler]

should a user be allowed to write Sender{}.connect(SomeReceiver{})?

i agree this is a better framing. of course, of Sender is a type they control, then we can't tell people to not call connect directly on it. but we can say that if Sender is library-provided, they cannot.

a related question is whether we want to allow execution::connect to, say, wrap the returned operation state for some reason. in which case, connect(sndr, rcvr) would not be equivalent to sndr.connect(rcvr).

[ispeters]

a related question is whether we want to allow execution::connect to, say, wrap the returned operation state for some reason. in which case, connect(sndr, rcvr) would not be equivalent to sndr.connect(rcvr).

That (connect wrapping sndr.connect(rcvr)) is how Unifex implements async stacks so I think that should be left open as an implementation option.

[lewissbaker]

a related question is whether we want to allow execution::connect to, say, wrap the returned operation state for some reason. in which case, connect(sndr, rcvr) would not be equivalent to sndr.connect(rcvr).

It is already the case that connect(sndr, rcvr) may not be the same as sndr.connect(rcvr) because connect(sndr, rcvr) applies transform_sender(sndr, get_env(rcvr)) before then trying to call .connect(rcvr) member function.