This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 3545. `std::pointer_traits` should be SFINAE-friendly

Section: 20.10.3 [pointer.traits] Status: Open Submitter: Glen Joseph Fernandes Opened: 2021-04-20 Last modified: 2022-02-23

Priority: 2

View other active issues in [pointer.traits].

View all other issues in [pointer.traits].

View all issues with Open status.

Discussion:

P1474R1 chose to use `std::to_address` (a mechanism of converting pointer-like types to raw pointers) for contiguous iterators. `std::to_address` provides an optional customization point via an optional member in `std::pointer_traits`. However all iterators are not pointers, and the primary template of `std::pointer_traits<Ptr>` requires that either `Ptr::element_type` is valid or `Ptr` is of the form `template<T, Args...>` or the `pointer_traits` specialization is ill-formed. This requires specializing `pointer_traits` for those contiguous iterator types which is inconvenient for users. P1474 should have also made `pointer_traits` SFINAE friendly.

[2021-05-10; Reflector poll]

Priority set to 2. Send to LEWG. Daniel: "there is no similar treatment for the `rebind` member template and I think it should be clarified whether `pointer_to`'s signature should exist and in which form in the offending case."

[2022-01-29; Daniel comments]

This issue has some overlap with LWG 3665 in regard to the question how we should handle the `rebind_alloc` member template of the `allocator_traits` template as specified by 20.10.8.2 [allocator.traits.types]/11. It would seem preferable to decide for the same approach in both cases.

[2022-02-22 LEWG telecon; Status changed: LEWG → Open]

No objection to unanimous consent for Jonathan's suggestion to make `pointer_traits` an empty class when there is no `element_type`. Jonathan to provide a paper.

Proposed resolution:

This wording is relative to N4885.

1. Modify 20.10.3.2 [pointer.traits.types] as indicated:

   > As additional drive-by fix the improper usage of the term "instantiation" has been corrected.

   >     using element_type = see below;

   > > -1- Type: `Ptr::element_type` if the qualified-id `Ptr::element_type` is valid and denotes a type (13.10.3 [temp.deduct]); otherwise, `T` if `Ptr` is a class template instantiation specialization of the form `SomePointer<T, Args>`, where `Args` is zero or more type arguments; otherwise, the specialization is ill-formed `pointer_traits` has no member `element_type`.