The working draft, N4842 currently has a single feature-test macro, __cpp_lib_jthread, that applies to both std::jthread and std::stop_token. std::jthread is defined in <thread> and std::stop_token/stop_source/stop_callback are defined in <stop_token>
std::jthread interface depends on std::stop_token and so an implementation cannot provide jthread without also providing stop_token. However, stop_token can be provided independent of jthread. Is it possible/likely that an implementation might provide an implementation of stop_token without also providing an implementation of jthread or of the new condition_variable_any methods? E.g. a freestanding platform that wants to support stop_token for cancellation of async operations but that does not support threads. For C++20, we may be able to get away with using __has_include(<stop_token>) to detect the existence of support for stop_token. However, I can imagine that there might be some extensions to stop_token in future standard versions that are independent of jthread and that we would want to be able to test for these extensions. Should we be adding a separate __cpp_lib_stop_token feature-test macro to allow testing of support for stop_token independently from jthread? Should this be done now or deferred to a future version if/when stop_token changes? If we were to add a __cpp_lib_stop_token now, would the existence of stop_token-taking methods to condition_variable_any be keyed off __cpp_lib_stop_token? Or would it be keyed off __cpp_lib_jthread? Or perhaps add a more specific macro like __cpp_lib_condition_variable_any_stop_token_methods? If we were to defer it then this would require checking both __cpp_lib_jthread and __cpp_lib_stop_token in future to differentiate between no stop_token, C++20 stop_token and C++Future stop_token. Or would we add a finer-grained macro for whatever the particular extension was? Eg. Say we added a std::stop_token::callback_type type alias in future, would we add a __cpp_lib_stop_token_callback_type_alias feature-test macro? - Lewis
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
