https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #17 from Peter Kasting <pkasting at google dot com> --- (In reply to Jonathan Wakely from comment #15) > (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 the reason to avoid it in the specific case the library happened to make use of std::to_address(). That's not necessarily reasoning that applies to other uses of std::to_address(). > > 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. I'm not sure how many more ways I can say that my interest in this being SFINAE-friendly is completely unrelated to libc++'s (or any other STL's) handling of contiguous_iterator. The committee added a tool, used it one place, made it hard to hold other places, and (per your previous summaries) has avoided making it more useful other places due to only thinking about things through the lens of this specific contiguous_iterator usage. I'm not using it for that. > If you think this should change, please take that through WG21. I don't > think we should deviate from the standard here. Yes, precisely. Per comment 8: "libstdc++ is standards-compliant as-is. We'll fix our code. I do think libc++'s behavior is more usable and an LWG issue would be nice." I don't have any connection to WG21. I was hoping someone here had the experience necessary to pass on this request to the committee. If not, so be it, it will die.
