You should also consider that it's probably not good to deprecate the case
where you append char to std::u8strng and append char8_t to std::string.

I imagine the warnings would be too noisy to pull that off in existing code
bases that make heavy use of these types and don't catch such conversions
already.

There is also the case of appending unsigned char to std::string I suppose.

On Mon, 18 May 2026 at 16:18, Qirong ZHANG via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, May 17, 2026 at 1:59 PM Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> > I'm much more concerned with the symmetry of the language. We don't want
> a
> > language where
> > T t;
> > t = u;
> > means something significantly different from
> > T t = u;
> > or where
> > t += u;
> > means something significantly different from
> > t = t + u;
> > Having types like that in the STL just makes it difficult to write
> generic
> > code — which is supposed to be C++'s strong suit.
>
> Thanks, this is very helpful.
>
> I agree that the stronger motivation is not implicit decimal formatting.
> The more fundamental issue is the irregularity of the expression domains:
>
> ```cpp
> T t = u;
> t = u;
>
> t += u;
> t = t + u;
> ```
>
> For `std::basic_string`, these pairs disagree in ways that most STL value
> types do not. That is a better framing than “someone might expect `s += 42`
> to append `"42"`”.
>
> I also take your point that treating only `operator+=` would make the
> paper look too ad hoc. A next revision should probably discuss both
> `operator=(CharT)` and `operator+=(CharT)` as part of the same
> scalar-to-character family, even if the proposed remedy is staged or
> conservative.
>
> I still think `push_back(CharT)` should remain out of scope, for exactly
> the reason you mention: it is an element-insertion operation, so `getc` /
> `int_type`-style code has a clear spelling there.
>
> At this point I suspect the most useful next step is not wording, but
> data: extend or add a clang-tidy-style check for `basic_string` scalar
> assignment and append, collect corpus results, and classify the hits into
> intentional code-unit append/assignment, likely bugs, char-arithmetic
> idioms, and unclear cases.
>
> A later paper could then compare several levels of intervention:
>
> 1. tooling only;
> 2. deprecate or reject only non-`CharT` arithmetic/enumeration arguments
> for `=` and `+=`;
> 3. reject all non-`CharT` arguments convertible to `CharT`;
> 4. the more radical cleanup of the char overloads themselves.
>
> I would be reluctant to jump directly to the most radical option without
> data, but I agree the paper should present the whole asymmetry rather than
> only `operator+=`.
>
> Thanks again.
>
> --
> Qirong Zhang
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>