This code would no longer compile in strict mode with C++20 enabled in Visual Studio 2019 (16.6.2, tools v142):
|
std::is_convertible<typename std::result_of<F &(Args...)>::type, R>::value, |
std::result_of has been permanently removed in C++20. Reference:
https://en.cppreference.com/w/cpp/types/result_of
Implementation needs to be rewritten.
One possible approach is to backport std::result_of into nostd::result_of
The other implementation approach is to rework this code to completely avoid the construct.
Visual Studio 2019 compiler takes very strict stance on removed features. There's also a temporary workaround flag that allows to enable deprecated features ( _HAS_DEPRECATED_RESULT_OF ). But I believe it is incorrect for common SDK API header to rely on a feature that's been permanently removed from C++ standard.
I also tested this to confirm that recent gcc-9 and clang-10 are both OK with that deprecated construct, even if a module is compiled in C++20 mode.. But what Visual C++ is doing (not supporting removed features) - seems like the right thing to do.
This code would no longer compile in strict mode with C++20 enabled in Visual Studio 2019 (16.6.2, tools v142):
opentelemetry-cpp/api/include/opentelemetry/nostd/function_ref.h
Line 66 in 9e5924c
std::result_of has been permanently removed in C++20. Reference:
https://en.cppreference.com/w/cpp/types/result_of
Implementation needs to be rewritten.
One possible approach is to backport std::result_of into nostd::result_of
The other implementation approach is to rework this code to completely avoid the construct.
Visual Studio 2019 compiler takes very strict stance on removed features. There's also a temporary workaround flag that allows to enable deprecated features ( _HAS_DEPRECATED_RESULT_OF ). But I believe it is incorrect for common SDK API header to rely on a feature that's been permanently removed from C++ standard.
I also tested this to confirm that recent gcc-9 and clang-10 are both OK with that deprecated construct, even if a module is compiled in C++20 mode.. But what Visual C++ is doing (not supporting removed features) - seems like the right thing to do.