RE: 31395511: "Don’t attempt to modify constant strings"

[Drew Adams]

> > But you can give bug#40671 a read, so see some context you might be
> missing.
> 
> Thanks, that's a pretty long read.  There is indeed a relation, but that
> bug (the first parts) is about modifying literal objects and this
> particular strangeness seems bigger than that.
>
> I totally agree it is undefined behaviour to change structure
> of literals (quoted or self-evaluating objects), also in
> Common Lisp, because compilers are probably allowed to reuse
> parts of the internal structure of such objects.

Yes.  But Common Lisp is a general-programming
language.  Elisp is for use with Emacs.  And it
has strings that have properties, like symbols.

> But that's a far cry from having two different manifestations
> of `equal` such objects _be_ the same object, but only for compiled
> code.  Emacs doesn't behave that way for quoted lists (fortunately), so
> I don't think it should behave that way for strings either.

+1.

> An "easy" solution would be to say: in Elisp, there
> are no string literals, period, because properties.

+1.  Clean, flexible (dunno how "easy").

> But that's likely expensive...

Do we have an idea how expensive?  Lots of things
are expensive.  And some of them are worth it.

OK, some Elisp code might make heavy, repeated use
of long strings, and maybe some such uses would pay
a penalty.  Not sure though that the penalty would
be large, or "too large".

And most Elisp code won't be like that, I expect.

Maybe we could have a Boolean variable (which could
be made file-local or buffer-local on demand).

You could turn it on in some scope or for some
extent, to enable some string optimization at the
cost of either an occasional gotcha or systematic
error-raising when you try to modify etc.

Maybe that decision would need to be made at
byte-compile time, or maybe the compiled code could
(at the cost of being larger) respect it.

> unless some clever copy-on-write semantics operate
> under the hood.  But I'm talking out of my elbow,
> I don't really know what's under the hood here.

Nor do I, obviously.  I just have a hunch that,
in general, string optimization isn't worth it for
most Lisp code used in Emacs - not worth the loss
of being able to comfortably and generally modify
string properties.