On Mon, Sep 8, 2025 at 10:42 AM Jonathan Wakely <jwak...@redhat.com> wrote:
> On Mon, 8 Sept 2025 at 07:46, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > > > > > On Fri, Sep 5, 2025 at 10:57 PM Jonathan Wakely <jwak...@redhat.com> > wrote: > >> > >> C++17 has a 'Requires:' precondition that the two random access iterator > >> types have the same value type. In C++20 that is a 'Mandates:' > >> requirement which we must diagnose. > >> > >> Although we could diagnose it in C++17, that might be a breaking change > >> for any users relying on it today. Also I am lazy and wanted to use > >> C++20's std::iter_value_t for the checks. So this only enforces the > >> requirement for C++20 and later. > > > > Could add a word here, on the motivation for checking that. If we allow > different > > types, we may get ones for which equality is transparent, but hashes are > not equal > > for equivalent object of different types. One example would be > chrono::durations, > > with different Ratios. > > Like so: > > #ifdef __glibcxx_concepts // >= C++20 > // Value types must be the same for hash function and predicate > // to give consistent results for lookup in the map. > static_assert(is_same_v<iter_value_t<_RAIter>, > iter_value_t<_RandomAccessIterator2>>); > #endif > Looks ok. I was thinking about the commit message, but the comment in code is even better. > > In theory, C++20 heterogeneous lookup for unordered containers should > make it possible to support heterogeneous value types here too. But > that would be a design question for LEWG, I think. > Yes, after making calls ill-formed, we could then relax the requirements for transparent wrappers.
