[WIP] get_completion_scheduler query for senders as of project goals

[RishabhRD]

get_completion_scheduler query is demonstrated in P2300R4 and it is also one of the project goals. We also need this for implementing unifex::bulk PR (#354). So, I am starting to implement this.

I am not an expert on this, so I would need continuous pointers on how we want to progress on this.

There are 2 phases of task of this feature I guess:

• Implementation of base get_completion_scheduler query that would just tag_invoke the call on the given sender.
• Implementing the get_completion_scheduler for each and every sender.

The latter one seems to be a lot of work to do, so based on maintainers decision we can do one of the following:

• This PR covers all the 2 phases
• This PR just covers the first one and there would be many subsequent PRs which would be implementation of get_completion_scheduler for different senders.

I may raise very simple questions on this PR as I am newbie on this (and possibly in C++ too :sweat_smile:)

[RishabhRD]

Currently I have implemented the basic generic get_completion_scheduler query. I need a confirmation from maintainers that everyone agrees with this implementation or some changes need to be done so that I can move ahead with next steps.

Thanks

[RishabhRD]

One thing I want to bring to notice... I am using set_done_t instead of set_stopped_t and the reason being to be compatible with other part of codebase that is still using the name done instead of stopped.

[RishabhRD]

I have implemented the get_completion_scheduler query for new_therad_context's scheduler's sender.

Still I need to be aware of how to test these. I have added some tests currently, that just checks if query returns the scheduler of same type as expected.

I have changed the original get_completion_scheduler query base implementation to not include enable_if and purely work on template specialization. However, there is a little code duplicacy that I would try to reduce... but if anyone want to suggest some options there, It would be so helpful.

@LeeHowes @ispeters maintainers feedback is important to get to know, if the implementation is on right path or not. I have done only some initial implementation till now, so it would be easy to change at this stage.

[LeeHowes]

This makes sense to me overall. The code is a bit noisy because you've managed to introduce a lot of formatting changes.

[RishabhRD]

Hi everyone, I was unable to work on PR from a long time as my laptop got broken... As @LeeHowes is agreeing with the the approach, I would be continuing with same approach for other files then....

[RishabhRD]

@RishabhRD could you revert the formatting changes? This will allow for easier review.

@janondrusek I just made a commit regarding reverting formatting changes in new_thread_context.hpp file... If any other file is not formatted well please comment too... Thanks!