Re: master f51f963: Fix some side-effecting uses of make-text-button

[Pip Cet]

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

>> But going backwards, toward some perhaps unneeded
>> optimization, in the direction of systematically
>> raising an error when trying to modify text
>> properties of a string, is not a good idea, IMO.
>
> I think there needs to be a clarification here: the issue is about
> modifying data (here specifically strings, but the issue applies to all
> other such data) that appears as literal in the code.

> This issue is not one of optimization (preventing those modifications
> would likely impose a slowdown, if anything) but one of detecting usage
> that is usually a bug (one that leads to people being utterly
> confused by the resulting behavior).

I don't see how literal data is special that way. If I expect a function
to look at a string argument, but it actually modifies its argument,
that's equally confusing. If I modify data that's been used in a hash
key, that's even more confusing. If I modify data in an image spec in a
Lisp callback from the image backend, Emacs will crash. These cases
deserve being thought about, too.

How many such bugs have appeared and been difficult to debug since pure
space essentially stopped existing when pdumper was introduced?

The cost of this isn't negligible; the single bit which I expect will be
kept for every string, cons cell, or vector isn't that significant, but
so far what's been proposed would be complicated to implement, explain,
and use. It would lead to some people developing a false sense of
security and others becoming insecure and copying everything needlessly
(and dangerously, for cyclic objects). And it would effectively prevent
any competing system of mutability, I fear.

For example, consider quasi-quoted literals: would those be immutable?
No matter what the answer to that question is, would people actually
remember?