Should `strictly_lazy_sender` be a concept?

[brycelelbach]

Do we have algorithms that plan to be constrained on whether execution::sender_traits<Sender>::is_strictly_lazy is true? Perhaps we should introduce a concept for this.

[griwes]

I don't know if we have such algorithms planned now - maybe on is one such?

[LeeHowes]

I'm not sure how many algorithms would constain on it alone - in that an algorithm could simply say it is strictly lazy whether or not its input is. It is very easy to imagine algorithms overloading on that constraint, though.

then, trivially, in your world would probably enqueue work. In our world it might be lightweight, zero overhead, and be inlined into the caller, as it is in libunifex. That distinction could be triggered on the type of the input, but more generally it could be triggered on the laziness - assuming that the implementation has to change in this case. We can easily project that to more complex algorithms.

So I don't know if we would necessarily define any standard library algorithms to check this, but an implementation might certainly want to choose to. So we should make that easy.

[griwes]

This is moot given the API split into lazy and non-lazy variants of algorithms, no?

[brycelelbach]

Yes.

-- Bryce Adelstein Lelbach aka wash (he/him/his) US Programming Language Standards (PL22) Chair ISO C++ Library Evolution Chair CppCon and C++Now Program Chair HPC Programming Models Architect @ NVIDIA

On Tue, Jun 1, 2021, 22:08 Michał Dominiak @.***> wrote:

This is moot given the API split into lazy and non-lazy variants of algorithms, no?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brycelelbach/wg21_p2300_executors/issues/20#issuecomment-852726171, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBG4UPXC5KV5MLJQYY7RTTQW4DZANCNFSM443Q7NLQ .

[LeeHowes]

Yes, it doesn't appear that we need this.