All deprecation messages indicate that sycl_ext_oneapi_enqueue_functions should be used instead of deprecated APIs.

But do I get it right that user also has a choice to use just regular SYCL 2020 parallel_for/single_task/parallel_for_work_group (queue and handler methods) but with kernel function object (which has a method to return properties) instead of a lambda? I.e. it seems like user doesn't have to use sycl_ext_oneapi_enqueue_functions. Maybe I am missing something.

Probably deprecation message should be fixed to indicate both available options.

Hi Artur, thanks for reviewing this! So just to let you know I've merged all commits in this PR into one in another PR #16728 to make the commit history cleaner. You can go there for further comments and check new updates.

And yes I agree with you -- the main point here is that if the user want to specify (compile-time) properties for a kernel, they can no longer specify such properties as arguments passed to (overloads of) single_task() and parallel_for(). Instead, they need to use kernel functors with the get(sycl::ext::oneapi::experimental::properties_tag) method to return properties. In other words, whether the single_task()/parallel_for() used are from original SYCL or extensions doesn't matter much (as long as they aren't among these deprecated ones). Sorry about the mis-wording here, I'll fix it in that other PR.

All deprecation messages indicate that sycl_ext_oneapi_enqueue_functions should be used instead of deprecated APIs.
But do I get it right that user also has a choice to use just regular SYCL 2020 parallel_for/single_task/parallel_for_work_group (queue and handler methods) but with kernel function object (which has a method to return properties) instead of a lambda? I.e. it seems like user doesn't have to use sycl_ext_oneapi_enqueue_functions. Maybe I am missing something.
Probably deprecation message should be fixed to indicate both available options.

Hi Artur, thanks for reviewing this! So just to let you know I've merged all commits in this PR into one in another PR #16728 to make the commit history cleaner. You can go there for further comments and check new updates.

And yes I agree with you -- the main point here is that if the user want to specify (compile-time) properties for a kernel, they can no longer specify such properties as arguments passed to (overloads of) single_task() and parallel_for(). Instead, they need to use kernel functors with the get(sycl::ext::oneapi::experimental::properties_tag) method to return properties. In other words, whether the single_task()/parallel_for() used are from original SYCL or extensions doesn't matter much (as long as they aren't among these deprecated ones). Sorry about the mis-wording here, I'll fix it in that other PR.

Sounds good, thank you!

Contents of this PR have been moved to #16728 to make the commit history cleaner. Closing this one to avoid duplication.