All executor facilities should be `constexpr` when possible

[ericniebler]

Issue by miscco
Wednesday Nov 10, 2021 at 08:06 GMT
Originally opened as NVIDIA/stdexec#246

---

Currently we have a some facilities, e.g. some adaptors and most factories that are not specified to be constexpr

I believe we should add constexpr support whenever possible. Yes it will not help at runtime, looking at recent improvements for compile time testing of user code, we should not restrict ourselves needlessly.

If there is no significant opposition coming up I will prepare a PR to fix that when possible

[ericniebler]

Comment by miscco
Sunday Jan 30, 2022 at 15:27 GMT

---

As we are starting an independent implementation, I would really like to get an opinion here.

I still do not see why we should make any of those facilities not constexpr

Of course they wont be used in a constexpr context most of the time but that is no argument in preventing it.

[lewissbaker]

Having an async framework that executes at compile-time also doesn't seem like a strong use-case to me, given we don't have I/O or threads available at constexpr time.

One concern with making things constexpr is that it will prevent implementation strategies that rely on manual lifetime management using reinterpret_cast. Also, the use of atomics in lots of algorithms is also problematic - although there is now a paper that should allow atomics to be constexpr.