Subject: Re: bug#70784: Abolish string resizing

From: Po Lu <[email-masked]>
Date: Mon, 06 May 2024 20:23:16 +0800

Eli Zaretskii <[email-masked]> writes:

> We are not going to abandon backward-compatibility considerations.
> But refusing to discuss significant changes just because they have
> compatibility issues is throwing the proverbial baby with the
> bathwater.  Refusing changes is of course 110% backward-compatible,
> but it has many disadvantages, to say the least.  Instead, we should
> see how to keep compatibility, to the extent that we consider it
> important, without blocking changes which could potentially help us
> adopting new technologies and improving performance.

These principles are no doubt valid in general, but please consider what
is the feature whose continued existence is being called into question!
`(aset string n foo)' has been possible and countenanced for ages, if
not forever, and, I trust, such behavior of a quarter-century's standing
is among the rudiments of a language that should not change without a
very compelling and immediate reason.  Theoretical or even demonstrable
performance wins, or the hoary old commonplace of facilitating the
adoption of new technologies, both to be found in the release notes of
proprietary programs everywhere, provide no such reason, simply as the
performance of strings has never been a source of user complaint.

Without such a plain justification and a clear strategy for evaluating
whether the results so produced meet expectations, there really is no
detriment in categorically dismissing proposals to alter them, until
such time, if ever, as these conditions are created.  The quantity of
user or package code that would be erratically broken is alone enough to
send shivers down one's spine.