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

--- Comment #14 from Peter Kasting <pkasting at google dot com> ---
(In reply to Jonathan Wakely from comment #13)
> As I said in comment 7, LWG considered this case and it was pointed out that
> the problem described can only occur if a type defines iterator_concept =
> contiguous_iterator; but then fails to actually provide the operations
> needed for a contiguous iterator (i.e. either a pointer_traits
> specialization with to_address or a sane operator->()).

That's fair. But that only considers the functionality of to_address() inside
this specific library use of it. If this tool is to be usable in other contexts
(which I argue it should be, or it shouldn't have been exposed to end users),
then said contexts may have nothing to do with iterators.

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. In such cases, having to_address() be SFINAE-friendly makes it far
easier to fall back to other handling for "not a pointer".

> A SFINAE-friendly std::to_address as implemented in libc++ means that such
> an iterator will fail to satisfy std::contiguous_iterator and will silently
> degrade to satosfying std::random_access_iterator only. It's not at all
> clear to me that silently degrading such an iterator (which very explicitly
> claims to be a contiguous iterator by defining iterator_concept to say so)
> would be an improvement. I'd rather get an error telling me the thing I
> thought was a contiguous iterator was not actually.

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.

Reply via email to