[romintomasetti]

Per [exec.sched] (I am not aware of a paper removing this requirement).

In #2256, a test was added that ensures all stdexec schedulers define the alias scheduler_concept, and that it derives from stdexec::scheduler_tag.

But IMO anyone implementing their own schedulers must also comply to this rule.

This is some sort of followup of:

• fix: provide the scheduler_concept nested alias on all stdexec schedulers (#2134) #2256

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[romintomasetti]

This now fails to compile.

@ericniebler I guess this defeats the principle of the explicit opt-in tag?

[romintomasetti]

See your comment #2256 (comment):

The scheduler concept requires the scheduler_concept nested alias. See [exec.sched]. I think the right fix here is for all of the schedulers in stdexec to provide that nested alias.

[romintomasetti]

I mean, it seems that my_behavioral_scheduler *should not model the scheduler concept (because it has the behavior of a scheduler, but not the scheduler_concept alias).

[ericniebler]

while agree with this PR in principle, it means that in practice some user-defined schedulers will suddenly stop satisfying the concept. i do not like breaking my users, at least not without some warning.

my preference would be a deprecation warning for schedulers that fail to provide the nested alias. this could be achieved with a test in schedule_t::operator(). after some time, we can strengthen the scheduler concept as you've shown here.

[romintomasetti]

@ericniebler Sure!

I just pushed a new version that does exactly that: provide 2 overloads of the schedule_t::operator(), with the one for schedulers that don't provide the nested alias marked as deprecated.