Fix __query_or CPO

[miscco]

The __query_or currently requires that the query is always of the form env.query(CPO, args...)

However, we also want that to work with types that are their own query, which would satisfy cpo(env, args...)

This is the case for ::cuda::get_stream(::cudaStream_t) and also for our memory resources

[davebayer]

pre-commit.ci autofix

[ericniebler]

today, given a query q and an env, there are two reasons why q(env) might be well-formed:

1. env.query(q) is well-formed, or
2. q has a fallback that returns a default value

today, __query_or is useful because it distinguishes between these cases. this change breaks that property.

the current semantics of __query_or also make it useful for implementing queries. get_allocator_t might look like this:

struct get_allocator_t {
  template <class Env>
  auto query(const Env& env, auto&&...) const noexcept {
    return __query_or(env, *this, std::allocator<std::byte>());
  }
};

the change proposed here would make this infinitely recurse.

would a __call_or or __invoke_or function, or a __with_default callable adaptor, meet your needs?

[miscco]

would a __call_or or __invoke_or function, or a __with_default callable adaptor, meet your needs?

I am impartial to what solution we use, but we need one that we can use uniformly in CCCL

[miscco]

@ericniebler I believe that is a bugfix, because a query with a non-const query method would satisfy __queryable_with<_Env, _Query, _Args...> but cannot be called here

[ericniebler]

true. a different fix would be for __queryable_with and friends to automatically const & qualify the Env argument.

[pciolkosz]

the change proposed here would make this infinitely recurse.

This is exactly what happened when I was trying a similar approach in #7113

[bernhardmgruber]

Btw, #7278 will add a bunch of tests for extracting streams from environments in CUB.

[github-actions]

😬 CI Workflow Results

🟥 Finished in 1h 46m: Pass: 95%/126 | Total: 1d 20h | Max: 1h 46m | Hits: 99%/250281

See results here.