Replace oneapi::dpl::__internal::__no_op by oneapi::dpl::identity

[SergeyKopienko]

This PR replaces the internal __no_op functor with the public oneapi::dpl::identity across tests and library headers, and removes the now-unused __no_op definition.

• Swap out all uses of oneapi::dpl::__internal::__no_op for oneapi::dpl::identity
• Add #include <functional> (or the library’s functional) where oneapi::dpl::identity is used
• Remove the __no_op struct from utils.h

[danhoeflinger]

This LGTM, but I think you need to rebase with main.

[akukanov]

I am concerned about including a public header file from internal files. As far as I can tell, there is no precedent of that yet.
Perhaps it's not an immediate problem, because now oneapi/dpl/functional and its dependencies do not include any internal headers, Nevertheless, maybe it makes sense to move the actual implementation to an internal header, separate from the public header, and use that for internal purposes.

What do others think?

[danhoeflinger]

Good point. I think it makes sense to move these functional definitions to an internal header.

[SergeyKopienko]

It's not a big deal to move this implementation into internal header.
But as far as this oneapi::dpl::identity was public before, my understanding that it should be public after move into internal header too, in oneapi::dpl namespace.
Correct?

[SergeyKopienko]

I am concerned about including a public header file from internal files. As far as I can tell, there is no precedent of that yet. Perhaps it's not an immediate problem, because now oneapi/dpl/functional and its dependencies do not include any internal headers, Nevertheless, maybe it makes sense to move the actual implementation to an internal header, separate from the public header, and use that for internal purposes.

What do others think?

Practically we had this include before but in a little bit another form, I found: https://github.com/search?q=repo%3Auxlfoundation%2FoneDPL%20%23include%20%22..%2Ffunctional%22&type=code

Example from

oneDPL/include/oneapi/dpl/pstl/hetero/algorithm_impl_hetero.h

Line 19 in 3f1c9a8

#include "../../functional"

:

#include "../../functional"

If we allow and prefer this form instead of #include "oneapi/dpl/functional" I will fix my changes.
May be it's also one of options for us?

[MikeDvorskiy]

maybe it makes sense to move the actual implementation to an internal header

Am I right that oneapi::dpl::identity remains in Public API , and we are talking about the implementation moving? And in the functional public header will contain just using oneapi::dpl::__internal::identity;? (and for the other function objects - minimum, maximum) ?

In that case we are breaking the spec a little bit, where it is saying "The oneDPL function objects are defined in the <oneapi/dpl/functional> header."

References:
oneDPL spec
oneDPL doc

[MikeDvorskiy]

```c++
#include "../../functional"

If we allow and prefer this form instead of #include "oneapi/dpl/functional" I will fix my changes.
May be it's also one of options for us?

That one "include" case is again for usage of oneapi::dpl::identity. So, we will not need #include "../../functional" if we decide to use a kind of oneapi::dpl::__internal::identity.

[SergeyKopienko]

My opinion - I would prefer to save changes as is, without move our own struct identity into some another places.

[danhoeflinger]

Its too bad the spec was written in that way...
I think it would probably be a benefit to adjusting the spec to use language more similar to the guide, where it doesn't specify where they are defined, but rather how you can get access to them. I would be incredibly surprised if moving them to an internal namespace and using an alias broke any user code.
I'm really not sure the best course here though, I'd be interested in @akukanov opinion.

[Copilot]

Pull Request Overview

This PR removes the internal __no_op functor and replaces its usages with the public oneapi::dpl::identity, eliminating duplicate implementations and ensuring consistent behavior across tests and library headers.

• Replace all instances of oneapi::dpl::__internal::__no_op with oneapi::dpl::identity
• Add necessary includes for functional support in affected files
• Remove the now-unused __no_op definition from utils.h

Reviewed Changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
test/parallel_api/iterator/transform_iterator_constructible.pass.cpp	Updated functor typedefs and test instantiations to use oneapi::dpl::identity
test/parallel_api/iterator/input_data_sweep.h	Added include for functional header and updated local functor usage
test/general/interface_check.pass.cpp	Removed unused include
include/oneapi/dpl/pstl/utils.h	Removed the __no_op struct definition
All other updated source files	Replaced internal __no_op usages with oneapi::dpl::identity and adjusted includes accordingly

Comments suppressed due to low confidence (3)

test/parallel_api/iterator/transform_iterator_constructible.pass.cpp:27

• [nitpick] Consider verifying that inheriting from oneapi::dpl::identity in noop_nodefault preserves the intended behavior; if custom behavior is needed, using composition rather than inheritance might be more appropriate.

struct noop_nodefault : oneapi::dpl::identity

include/oneapi/dpl/pstl/hetero/dpcpp/unseq_backend_sycl.h:27

• [nitpick] Verify that using the relative include path for the functional header remains robust across different build environments; consider using a canonical include path if available.

#include "../../../functional" // for oneapi::dpl::identity

include/oneapi/dpl/pstl/glue_numeric_impl.h:19

• [nitpick] Ensure the relative include path for the functional header adheres to the project-wide conventions to prevent future maintenance issues.

#include "../functional" // for oneapi::dpl::identity