I've been generally trying to reduce the number of special CL_HPP_FOO preprocessor defines in these C++ headers, but I think it would be good to add a preprocessor define to explicitly opt-in to provisional extensions or features. This will avoid breaking code that doesn't use these features if their definitions change as part of the provisional review process, say by removing or renaming functions or enumerants.
Assuming we want to do this, the hardest thing will probably be deciding on a name. Some options:
CL_HPP_ENABLE_PROVISIONAL_FEATURES
CL_HPP_ENABLE_EXPERIMENTAL_FEATURES
CL_HPP_USE_PROVISIONAL_FEATURES
There are already several defines to ENABLE or USE features, such as CL_HPP_ENABLE_EXCEPTIONS and CL_HPP_USE_CL_SUB_GROUPS_KHR, so although I have a slight preference for ENABLE I think we could go either way.
I've been generally trying to reduce the number of special
CL_HPP_FOOpreprocessor defines in these C++ headers, but I think it would be good to add a preprocessor define to explicitly opt-in to provisional extensions or features. This will avoid breaking code that doesn't use these features if their definitions change as part of the provisional review process, say by removing or renaming functions or enumerants.Assuming we want to do this, the hardest thing will probably be deciding on a name. Some options:
CL_HPP_ENABLE_PROVISIONAL_FEATURESCL_HPP_ENABLE_EXPERIMENTAL_FEATURESCL_HPP_USE_PROVISIONAL_FEATURESThere are already several defines to
ENABLEorUSEfeatures, such asCL_HPP_ENABLE_EXCEPTIONSandCL_HPP_USE_CL_SUB_GROUPS_KHR, so although I have a slight preference forENABLEI think we could go either way.