Kokkos: Easier KOKKOS_ENABLE_DEPRECATED_CODE transition.

[vbrunini]

I'd like to make a general request that where possible the replacement functions that apps are supposed to switch to when removing deprecated code not be ifdef'd out when KOKKOS_ENABLE_DEPRECATED_CODE is enabled. This makes the transition easier on apps by letting them unconditionally switch to the new functions and still build whether or not deprecated code is enabled.

A motivating example is Kokkos::DefaultHostExecutionSpace::(impl_)hardware_thread_id() (as well as a number of other functions on the execution spaces that have had impl_ added to the beginning of the function name). Right now the definitions of the new impl_* versions are in the else block of an ifdef KOKKOS_ENABLE_DEPRECATED_CODE. This means that apps that switch to the new versions either need to ifdef all of their call sites as well, or lose the ability to build when deprecated code is enabled. If the new impl_* versions were also provided when deprecated code is enabled we could switch directly to them and not have to worry about any ifdefs.

[crtrott]

Actually you are not supposed to use the new impl_ functions, that is why they are called impl_. You are supposed to remove usage of those functions. See https://github.com/kokkos/kokkos/wiki/DeprecationPage

Basically these functions were deprecated outright. We have internally some need to use those functions to implement the more general replacement mechanisms, and that is why the impl_ versions now exists. But you shouldn't call these functions in user code anymore, and we reserve the right to make unannounced changes to all functions prefixed with impl_ up to and including removal of the functions without warning.

The issue of those functions was that they never existed for all backends, and that on some backends you can't even implement them.

[vbrunini]

Ok, I can switch the code in question to use UniqueToken. Just want to confirm that the general policy is that code that builds with KOKKOS_ENABLE_DEPRECATED_CODE off should also build with it on assuming that it is only using the un-deprecated public interface.

[crtrott]

Yeah this should be true, and I think (hope ;-) ) it is right now.