https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #6 from Jonathan Wakely ---
Please don't waste time on the volatile question. What does it mean to lookup a
volatile value that could change at any moment? What is the library even
supposed to do with a volatile int& there, read it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #5 from Arthur O'Dwyer ---
> I think this also means the standard transparent-compare overload is
> underconstrained [...] m[k] for volatile k is a soft/constraint error if
the comparator is non-transparent, but is a hard error if t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #4 from Patrick Palka ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #3 from Patrick Palka ---
(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 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #2 from Arthur O'Dwyer ---
(In reply to Patrick Palka from comment #1)
> Confirmed, that fix looks good to me.
>
> FWIW our template operator[] is just the standard
> https://eel.is/c++draft/flat.map#access-4 with more generalized c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2025-05-27
Status|UNCONFIRM
