Details
- Reviewers
ldionne
Diff Detail
- Repository
- rPSTL pstl
- Build Status
Buildable 28969 Build 28968: arc lint + arc unit
Event Timeline
include/pstl/internal/algorithm_impl.h | ||
---|---|---|
68 | Those calls should stay qualified. If a user had a function called __parallel_or and _ForwardIterator were a custom type, we could end up calling their function because of ADL. I know __parallel_or is a reserved name, but I like being consistent especially when it comes to ADL. WDYT? |
@ldionne - When Intel added multiple new algorithm implementations, they did so without qualifying these calls. This led to a situation where some were and some weren't qualified.
I chose to make them uniform during the uglification pass, I have a subsequent patch that I'm working on that adds back the namespace qualifications uniformly.
I would like to see this patch accepted as is, because that new patch relies on this as a baseline, and it doesn't really change the status quo where we have many calls that are not qualified in the code.
"I know __parallel_or is a reserved name, but I like being consistent especially when it comes to ADL. WDYT?"
According to @rsmith and @jwakely it's not just about consistency -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497
So we need to have it and have it applied uniformly.
Those calls should stay qualified. If a user had a function called __parallel_or and _ForwardIterator were a custom type, we could end up calling their function because of ADL.
I know __parallel_or is a reserved name, but I like being consistent especially when it comes to ADL. WDYT?