search

cplusplus / sender-receiver

Issues list for P2300
Apache License 2.0
20 stars 3 forks source link

All executor facilities should be `constexpr` when possible #119

Open ericniebler opened 10 months ago

ericniebler commented 10 months ago

Issue by miscco Wednesday Nov 10, 2021 at 08:06 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/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 commented 10 months ago

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 commented 3 months ago

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.