added some components needed for sender concepts #5
Conversation
dietmarkuehl
force-pushed
the
add-sender-concept
branch
from
3ed6667 to
4f3c973
Compare
| @@ -2,7 +2,7 @@ | |||
| # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | |||
There was a problem hiding this comment.
Is the plan to do cmake stuff later?
There was a problem hiding this comment.
hmm ok there's a cmake file later....
There was a problem hiding this comment.
I'm using make to drive my builds even if the main work is done by cmake: the default target just runs cmake to build and test things. There are a few other target like a naïve dependency checker and something to build one header suitable for Compiler Explorer: I'd forget how to run these if I don't encode the "procedure" somewhere.
tl;dr: it uses cmake already! make is just a "convenience" frontend you don't have to use.
| template <typename Query, typename... Args> | ||
| requires (not ::Beman::Execution26::forwarding_query(::std::remove_cvref_t<Query>())) | ||
| constexpr auto query(Query&& q, Args&&... args) const | ||
| = BEMAN_EXECUTION26_DELETE("the used query is not forwardable"); |
There was a problem hiding this comment.
delete with a message -- implemented with backward compatibility?
There was a problem hiding this comment.
Well, delete with message isn't implemented in any of the compilers I'm actually using (it seems it is coming with gcc-15 and clang-19). I should probably build a current version and see if it actually works.
| return sender_meta<decltype(tag), decltype(data), ::std::tuple<decltype(children)...>>; | ||
| #endif | ||
| using sender_type = ::std::remove_cvref_t<Sender>; | ||
| static constexpr ::Beman::Execution26::Detail::sender_any_t any{}; |
There was a problem hiding this comment.
obviously we're in a different namespace here, but would we want to avoid the name any -- just to not confuse with std::any? any_t perhaps? Or maybe this is actually just a temporary shim?
There was a problem hiding this comment.
It is an interesting question whether that is temporary shim or something more substantial: the necessary functionality to introduce packs with structured bindings hasn't made it into the C++ draft, yet! Without that, I don't think there is portable way to implement this necessary functionality.
The type alias doesn't need to be named any, though. As it shows up often, I'd want it to be short. I'll rename to at ("any type").
|
|
||
| // ---------------------------------------------------------------------------- | ||
|
|
||
| namespace Beman::Execution26 |
There was a problem hiding this comment.
::Detail? the file is under the directory?
There was a problem hiding this comment.
This comment is interesting: sender_in is supposed to be in std::execution. However, the file sender_in.hpp isn't anything the standard defines: the header is <execution> which is modelled by include/Beman/Execution26/execution.hpp which would eventually include sender_in.hpp.
I can't cope with creating just one header [manually], i.e., I'm organising my implementation mostly into one component per header. The header name is an implementation-specific detail, the name within is (in this case) a standard name. As a result, the namespace doesn't quite line up with the path.
Maybe the proper way is to actually define sender_in in the Detail namespace and get it into the standard namespace using a suitable alias (and, obviously, do so far other names, too). That sounds like a reasonable thing to do and I'll make a pass through the code to change it accordingly.
|
I took a pass thru -- didn't see too much except maybe on missing namespace. It sure takes a lot of infrastructure to get anywhere with this proposal lol. |
Thank you for having a look! Although already quite big, this PR isn't even done, yet! I'm primarily using it to run the github CI to make sure the code compiles with clang, gcc, and MSVC++. With respect to "a lot of infrastructure": despite all that code, I don't even have any sender working at all! I know because |
No description provided.