; > Given that the operator[] that we are forading to is implemented as:
> > { return try_emplace(std::forward<_Key2>(__x)).first->second; }
> > I would just call try_emplace directly:
>
> Good point, the implementation is a simple one-liner either way, and it
>
iven that the operator[] that we are forading to is implemented as:
> { return try_emplace(std::forward<_Key2>(__x)).first->second; }
> I would just call try_emplace directly:
Good point, the implementation is a simple one-liner either way, and it
addresses the volatile k
On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> The 'volatile' issue from that PR Will be fixed in a separate patch as
> operator[] isn't the only operation that's affected.
>
> -- >8 --
>
> The const lvalue operator[] over
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
The 'volatile' issue from that PR Will be fixed in a separate patch as
operator[] isn't the only operation that's affected.
-- >8 --
The const lvalue operator[] overload wasn't properly forwarding the key
type to the generic overload
