On Fri, 13 Feb 2026 at 09:05, Tomasz Kaminski <[email protected]> wrote: > > > > On Fri, Feb 13, 2026 at 12:27 AM Jonathan Wakely <[email protected]> > wrote: >> >> >> >> On Thu, 12 Feb 2026, 22:00 Tomasz Kamiński, <[email protected]> wrote: >>> >>> Presence implicit conversion from int to it's allocator, makes the following >>> makes constructing >> >> >> There seem to be some extra words here, "makes the following makes >> constructing" >> >>> string from rvalue of same string type and int ambigous, >>> as none of following candidates is better: >>> basic_string(basic_string&&, allocator_type) >>> // conversion from int to allocator for second argument >>> basic_string(const basic_string&, int, allocator_type) >>> // reference adjustment for first argument >>> >>> This makes __gnu_test:uneq_allocator(int) constructor explicit, to avoid >>> above issues. >> >> >> Users can still have the same problems with their own allocators, but >> they're not our fault, and there nothing we can do about that. > > We can do something about it, i.e. add the rvalues overloads for "substring" > constructor. > basic_string(basic_string&&, int, allocator_type). > I found the problem because I have added above to SSO string, and my test > emitted > ambiguity warning for COW string. But I still think that this ambiguity is > what you deserve > if you write an allocator that can be implicitly constructed from int. > > So unless we get a real user complaint, I do not feel like we should bend to > fix it.
I agree. N.B. please fix "cosntructor" in the first line of the commit log. >> >> OK with the wording cleaned up above.
