https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Patrick Palka from comment #3) > (In reply to Arthur O'Dwyer from comment #2) > > But I think a better answer in this case is "because using > > a volatile index *will not actually compile*, so flat_map shouldn't > > gratuitously advertise that signature to SFINAE." > > https://godbolt.org/z/bdTK7nPKG > Good point.. I think this also means the standard transparent-compare > overload is underconstrained: https://godbolt.org/z/354GTTsxG So with the current wording, m[k] for volatile k is a soft/constraint error if the comparator is non-transparent, but is a hard error if the comparator is transparent. Naturally one would expect m[k] to behave consistently regardless of comparator transparency, so the current behavior seems like a wording defect. It's not clear whether the solution is to uniformly accept, or reject, volatile k.
