https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #14 from Giuseppe D'Angelo <dangelog at gmail dot com> --- Hello, (In reply to Glen Joseph Fernandes from comment #11) > > if it can never be used. > > You're misunderstanding. to_address(p) requires that pointer_traits<P> is > valid. It just doesn't need to have a to_address member function. Thank you for clarifying this. I think the wording in the standard is very unfortunate, but combined with the realization that pointer_traits isn't SFINAE-friendly, then it's the only intended meaning. > If (for contiguous iterators, which came later) you want pointer_traits<X> > to be valid even when X does not have element_type, that is a design change > to pointer_traits. One might claim that pointer_traits should become SFINAE-friendly (like C++17's iterator_traits), but sure, that's a different design question and not necessarily needed here. (In reply to Jonathan Wakely from comment #12) > (In reply to Giuseppe D'Angelo from comment #10) > > (By the way, finding this bug is quite hard. Could "address_of" be changed > > to "to_address" , in the bug description? > > Done. Thank you! (In reply to Arthur O'Dwyer from comment #13) > > And are you recommending that everyone who defines their custom contiguous > > iterators specializes pointer_traits for them? Call it _quite_ annoying... > > Definitely not! When you define a contiguous iterator type, you should just > give it a sixth nested typedef alongside the other five (or three in C++20): > `using element_type = value_type;`. This enables contiguous-iterator > machinery. > See > https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a- > contiguous-iterator/66050521#66050521 This gets evil really quick: the presence of both value_type and element_type in an contiguous iterator will make you smash face-first against LWG3446, which isn't implemented in GCC 10 AFAICS. https://cplusplus.github.io/LWG/issue3446 What's more, the accepted resolution wording for it appears to be wrong: template<classhas-member-value-type T> requires has-member-element-type<T> && same_as<remove_cv_t<typename T::element_type>, remove_cv_t<typename T::value_type>> struct indirectly_readable_traits<T> : cond-value-type<typename T::value_type> { }; For const iterators, value_type is actually different from element_type (!). Thankfully libstdc++ seems to have considered this as a non-standard extension, https://github.com/gcc-mirror/gcc/commit/186aa6304570e15065f31482e9c27326a3a6679f To summarize: * should a wording defect be raised against std::to_address(Ptr), to state that pointer_traits<Ptr> being well-formed is actually a prerequisite? * should LWG3446's resolution be amended? * if there's going to be a GCC 10.3, is the commit above solving LWG3446 going to be cherry-picked into it? Otherwise, either one blacklists GCC 10, or has to specialize pointer_traits there as a workaround (?). Thank you all for the insightful comments.
