[Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits

[whatwasthataddress at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416

Bug ID: 96416
   Summary: address_of() is broken by static_assert in
pointer_traits
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whatwasthataddress at gmail dot com
  Target Milestone: ---

pointer_traits contains this static_assert:

  static_assert(!is_same::value,
  "pointer type defines element_type or is like SomePointer");

When trying to use address_of() with an iterator that has a usable
operator->(), address_of() fails because the static_assert causes a hard error
in the trailing decltype here:

  template
constexpr auto
__to_address(const _Ptr& __ptr) noexcept
-> decltype(std::pointer_traits<_Ptr>::to_address(__ptr))
{ return std::pointer_traits<_Ptr>::to_address(__ptr); }

  template
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
  if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
  else
return std::__to_address(__ptr.operator->());
}

When I comment out the static_assert, to_address() works with the iterator in
question.

[Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits

[whatwasthataddress at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416

--- Comment #2 from Zach Laine  ---
Fair enough.  [pointer.conversion] says that to_pointer(const Ptr& p) is
"pointer_­traits​::​to_­address(p) if that expression is well-formed (see
[pointer.traits.optmem]), otherwise to_­address(p.operator->())".  Do we then
have a spec bug?

[Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits

[whatwasthataddress at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416

--- Comment #24 from Zach Laine  ---
Sorry for the delay.  I confirmed that this makes my case well-formed with
releases/gcc-11, and that it's ill-formed with GCC 11.2 and GCC 10.x.