Date: Mon, 16 Dec 2019 21:47:08 +0000
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
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
Received on 2019-12-16 15:49:40