Date: Sat, 9 Dec 2023 18:08:33 +0800
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?
This should make the code explicit and clear, and would not cause
headaches to the code writers in typical use cases either. I suppose
such specializations are generally very short.
Yongwei
>
>
>
> 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?
This should make the code explicit and clear, and would not cause
headaches to the code writers in typical use cases either. I suppose
such specializations are generally very short.
Yongwei
Received on 2023-12-09 10:08:46