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.