https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Peter Kasting from comment #14)
> And you are right, it's possible to reimplement concepts around "is this
> even legal to pass to to_address()", which is basically what we're doing to
> address this in Chromium. But that's pretty unfriendly to most usage; if
> you're in a context where you are reaching for to_address() to begin with,
> it's likely because you're templated and don't know that a simpler thing
> like `&*ptr` is valid.
The reason to avoid &*ptr is because it's undefined behaviour on a past-the-end
iterator, not because it might be ill-formed for some template argument types.
> That's fair, but isn't that implementable by simply making the definition of
> contiguous_iterator explicitly hard error in this case? That is, an
> SFINAE-friendly to_address() wouldn't prevent you from diagnosing this
> particular usage site as incorrect.
The rationale for making it SFINAE-friendly in libc++ was to *not* give an
error for that case. Making it SFINAE-friendly but restoring the error in that
case would remove the reason to have made it SFINAE-friendly in the first
place.
If you think this should change, please take that through WG21. I don't think
we should deviate from the standard here.
