LWG3545 "std::pointer_traits should be SFINAE-friendly" is maybe related. It's currently unclear what the difference is between "contiguous iterator" (for which `std::to_address` is required to work) and "fancy pointer" or "pointer-like type" (for which both `pointer_traits` and `std::to_address` are required to work). The precondition for __wrap_iter is that it's for use only with fancy pointers, i.e., things that should in C++20 be unambiguously contiguous iterators... but because of legacy code, we can't actually _enforce_ this precondition. We sanity-check it only as far as verifying that the fancy-pointer type we're given is at least a random-access iterator. We explicitly do _not_ try to instantiate `pointer_traits<_Iter>`, because legacy user-defined fancy pointer types might not support that. (The metaprogramming around `pointer_traits` is vastly different and more stringent in C++20 from how it was in C++11/14/17.) Instead, we compute `element_type` directly from `reference`. Meanwhile, `__is_cpp17_contiguous_iterator` is used (only) for optimizations in <algorithm>, so in C++17 we must be very careful not to apply those optimizations to arbitrary user-defined types (in particular we mustn't assume that any old random-access iterator with an `element_type` is contiguous). In C++20 we can liberally assume that the optimizations should be applied to any user-defined iterator types that advertise themselves as contiguous via `iterator_category` and/or `iterator_concept` (which automatically includes `__wrap_iter`). Our `__wrap_iter` now correctly advertises itself as a contiguous iterator in C++20, and produces the correct `pointer_traits<WI>::element_type`; this is now tested.
Refs D101396
Heh, thanks for fixing this :P