Misleading compile error for start_detached when not included

[Zhang-JK]

I am not sure if this is an issue that should be fixed
For the following code, im not including <exec/start_detached.hpp> for calling exec::start_detached:

#include <stdexec/execution.hpp>
// missing include file
// #include <exec/start_detached.hpp>

void do_some_work() {
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
}

int main() {
    auto work = stdexec::just() | stdexec::then([] {
        do_some_work();
    });

    exec::start_detached(std::move(work));

    std::this_thread::sleep_for(std::chrono::seconds(1));
    return 0;
}

and the compiler gives error:

-> % g++ ./include-issue.cpp -I/some/random/path/stdexec/include -std=c++20 -ltbb
./include-issue.cpp: In function ‘int main()’:
./include-issue.cpp:14:25: error: no match for call to ‘(const experimental::execution::start_detached_t) (std::remove_reference<stdexec::{anonymous}::__sexpr<<lambda closure object>stdexec::<lambda()>()>&>::type)’
   14 |     exec::start_detached(std::move(work));
      |     ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~

1. it's a bit misleading the compiler reporting "no match call" instead of "not defined", there might be a forward declarations seen by compiler
2. given that im only including files under stdexec, seeing forward declarations from exec might not be an expected behavior?

[ericniebler]

this is an unfortunate but temporary state of affairs. there used to be a stdexec::start_detached algorithm because it was part of P2300. when it was removed from the proposal, start_detached moved to the exec namespace, but i left breadcrumbs so that code that uses stdexec::start_detached would continue compiling, albeit with a deprecation warning.

that's where things stand today. after a period of time, i will remove the deprecated aliases from the stdexec namespace, and this will cease to be an issue.

if you have a suggestion about how to improve the diagnostic in the meantime, i'm all ears.