bug#70784: Abolish string resizing

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Sun, 5 May 2024 14:33:51 +0200
> 
> The Elisp ability to resize strings is high-cost, low-benefit, so we should 
> abolish it.
> 
> Strings are performance-critical, and the split allocation (fixed-size 
> metadata + variable-size data) and its indirections are not free. This is one 
> reason why strings are comparatively expensive in Elisp compared to other 
> languages.
> 
> With MPS there is even no use for the special-purpose string data defragger 
> in the current GC.
> 
> String resizing occurs in exactly one place: `aset` on strings, and then only 
> when the mutation alters the string size, in either of two cases:
> 
> * When a unibyte string byte is set to a non-byte value (> 255), which also 
> forces the string to become multibyte.
> * When a multibyte string char is set to a char of different length.
> 
> String mutation itself is very rare these days, and resizing string mutation 
> exceptionally so.
> 
> Best and simplest would be to just turn resizing `aset` on strings into an 
> error now. As an alternative, we could start warning about it now and make it 
> an error in the next release. The (trivial) patches exist.

How many places in our own sources call aset on strings?

> 
> Note that this is not a proposal for abolishing string mutation in general. 
> For example, `clear-string` would still work on any string, as would 
> arbitrary closed mutations on unibyte strings and on ASCII multibyte strings.

I'm not yet sure this is a good idea, but one thing I'm sure: it is
not for Emacs 30.  So if we decide to go this way, let's delay
merging the changes until after the emacs-30 branch is cut, which
should happen in a week or two.

Thanks.