OK, I see where is the problem. When switch backed to c++17:
uppsrc/Core/CoWork.h (186): warning: explicit capture of 'this' with a capture default of '=' is a C++20 extension [-Wc++20-extensions]

It looks like it was in only one place. For the rest I don't use [=, this], instead I use more specific targeting. The only places that needed to be changed is AsyncWork::Impl. Now it is:
void Do(Function&& f, Args&&... args) { co.Do([=, *this]() { ret = f(args...); }); }

OK, I see where is the problem. When switch backed to c++17: uppsrc/Core/CoWork.h (186): warning: explicit capture of 'this' with a capture default of '=' is a C++20 extension [-Wc++20-extensions]

It looks like it was in only one place. For the rest I don't use [=, this], instead I use more specific targeting. The only places that needed to be changed is AsyncWork::Impl. Now it is: void Do(Function&& f, Args&&... args) { co.Do([=, *this]() { ret = f(args...); }); }

@klugier
Well, this should work if we don't want implicit copy, but it is too verbose and IMO, very ugly. :)

template<class Function, class... Args> 
void Do(Function&& f, Args&&... args) {  
        co.Do([this, f = std::forward<Function>(f), args = std::forward_as_tuple(args...)]() { 
        ret = std::apply(f, args); 
    }); 
}

At this point: Let us wait 2 years, then switch to C++20. It is not only uppsrc, but also client apps...

We should adopt this change sooner rather than later. The main problem is that manually switching to a newer standard pollutes compilation logs with warnings. This change won't hurt compatibility with C++17, as the updated code is perfectly valid for that standard.

I don't propose a single, massive change. My plan is to start with several packages from uppsrc and submit the fixes in a few pull requests. Ultimately, all the code within our official distribution will be updated.

For client-side code, we'll fix what's on our end. It will be the client's decision whether to fix their own code or tolerate the compilation warnings. In this scenario, we'll be clear that we aren't responsible for these warnings.

We should adopt this change sooner rather than later. The main problem is that manually switching to a newer standard pollutes compilation logs with warnings. This change won't hurt compatibility with C++17, as the updated code is perfectly valid for that standard.

I don't propose a single, massive change. My plan is to start with several packages from uppsrc and submit the fixes in a few pull requests. Ultimately, all the code within our official distribution will be updated.

For client-side code, we'll fix what's on our end. It will be the client's decision whether to fix their own code or tolerate the compilation warnings. In this scenario, we'll be clear that we aren't responsible for these warnings.

Well, for a starter, I'll see if I can get the SSH package comply with the C++20 rule without breaking anything. I think it would be trivial because all lambda calls are internal and they don't do any magic.