bug#70784: Abolish string resizing

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, it's not "immemorial", it's just old:
>
>     commit 3c9de1afcde82a99137721436c822059cce79b5b
>     Author: Kenichi Handa <handa@gnu.org>
>     Date:   Fri Jul 21 06:45:30 2000 +0000

That's _23_, approaching 24 years, in the past, or 1 generation exactly.
To put this into perspective, a mere 2 years and 7 months after the
introduction of multibyte strings.

>
>         (Faset): Allow storing any multibyte character in a string.  Convert
>         unibyte string to multibyte if necessary.
>
> IOW, since Emacs-21.1.

Only two releases after the distinction between multibyte and unibyte
strings was introduced.  Evidently, this departure from traditional
array behavior was seen as a misdesign at the time, and we should know
better than to second-guess old design decisions, especially those from
a past when computer memory and performance were far scarcer commodities
than today.

> As for improvements, like a lot of refactoring and maintenance work,
> there isn't any immediate benefit.  But it's a "feature" which is *very*
> rarely used (thank god: it makes a notionally constant time operation
> take time proportional to the size of the string, so if it were used
> often we would have heard complaints about the poor performance) and
> which imposes pretty significant implementation constraints, so it's
> definitely detrimental to long term evolution.

Placing quotation marks around the word "feature" does not make it any
less of a feature, and if reports of performance woes be the judge of
whether a feature is sufficiently disused to justify removal, then, why,
virtually all (vastly underreported) sub-optimal code in Emacs would be
eligible for immediate deletion attended by irritating pop-up warnings.