Per http://eel.is/c++draft/range.adaptors#range.all.general-2, views::all
is a range adaptor object, but not a CPO. We don't need to define it like
a CPO to avoid name collisions with hidden friend functions of the same
name.
Details
- Reviewers
• Quuxplusone - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
https://eel.is/c++draft/range.adaptor.object#2
A range adaptor object is a customization point object...
Hmm, fair enough, I missed that. However, I still stand by the fact that we don't need to use the inline namespace trick because we're not trying to "overload" a name that may already exist in the same namespace. In other words, views::all and ranges::swap are fundamentally different, because views::all is never expected to be customized by users. By the way, that makes me question why range adaptors are considered CPOs - am I missing something or do they really not need this inline namespace dance?
So I can change the commit message to not lie about views::all not being a CPO, but I'd still like someone to explain to me why a function object like views::all needs to be in an inline namespace. I understand why ranges::swap is, but not why views::all is. Anyone?
I just talked to Arthur and was convinced that even though we don't *need* views::all to be implemented as a CPO, it's better to do it for consistency. Abandoning.