Re: `aset` on strings, changing the size in bytes

[Stefan Monnier]

>> >> Or we could define it to replace a substring:
>> >>    (setq s (srep s from to newsubstring))
>> > Why not have aset do this under the hood?  Then we won't need to ask
>> > people to change code that worked for decades.
>> It's unclear what you mean by that
> I meant to make aset cons a new string when it turns out the original
> one's data is too small to include the new contents.
>> the semantics of aset is to modify the original string, changing
>> that would surely break code that worked for decades.
> But if we are going to tell people aset won't work in those cases,
> that code will be broken as well, no?

So, IIUC you're suggesting to change `aset` so that when the string
needs to be resized, it does not modify the provided string but instead
returns a new string (with the requested modification).

The idea being that my suggestion would cause `aset` to treat such
a case as an error, so instead of signaling an error we could introduce
this new behavior.

Right?

If so, I agree that it's an option, but I think it'll be problematic in
practice:
- most callers of `aset` don't look at the return value, so if they
  expect the old behavior they'll just go on blissfully unaware that
  their `aset` did not happen.
- given the fact that we're breaking backward compatibility, it's
  important to introduce the change gradually, with warnings emitted
  during the transition to bring attention to possible troubles ahead.
  But with your suggested final behavior, I'm not sure how we could
  detect problematic uses.

IOW, the benefit of sset is that once we introduce sset we can:
- first change aset so that it emits a warning when it needs to allocate
  a new string.
- later turn this warning into an error.


        Stefan