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