On Sat, 9 Dec 2023 at 20:15, Andrey Semashev via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On 12/9/23 13:08, Yongwei Wu via Std-Discussion wrote:
> > On Sat, 9 Dec 2023 at 05:02, Jens Maurer <jens.maurer_at_[hidden]> wrote:
> >>
> >>
> >>
> >> On 08/12/2023 07.46, Yongwei Wu via Std-Discussion wrote:
> >>> There are quite a few specialization points in the std namespace that
> >>> a user-defined type can leverage, e.g.:
> >>>
> >>> - std::hash (for use as key in the unordered associative containers)
> >>> - std::is_error_code_enum (to act like an error code)
> >>> - std::tuple_size and std::tuple_element (to be tuple-like)
> >>>
> >>> Unfortunately, specialization of such templates requires quitting the
> >>> current namespace and adding specialization at the global or std
> >>> namespace, which is extremely inconvenient.
> >>
> >>> Another issue Mike mentioned was how names should be resolved in the
> >>> specialization: should we choose first a symbol in the "current"
> >>> namespace, or a symbol in the "specialized" namespace? I do not hold a
> >>> strong opinion here, but either solution seems better than having to
> >>> exit to the global namespace.
> >>
> >> And, as far as I remember, this is the main pain point:
> >> Which lookup rules do we pick?
> >>
> >> Obviously, that needs to be a considered decision, with some analysis
> >> in a paper.
> >
> > A thought: How about requiring all non-local symbols be fully
> > qualified, thus circumventing this issue?
>
> Simplifying name qualification is one of the primary reasons to want to
> specialize a template in a foreign namespace. Namespace opening/closing
> is a minor issue compared to that, especially with C++17 nested
> namespace syntax. If simplifying name qualification is off the table, I
> would say the proposal isn't worthwhile.

My motivation is mainly from code generation (whether a tool or a
macro). The knowledge of the "current namespace" may not be present,
and the requirement to exit to the global namespace could be
devastating. So the No. 1 issue for me is the need to quit the current
namespace.

This said, I agree that resolving symbols normally is intuitive and
the least surprising.

Yongwei