bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]

[Mattias Engdegård]

11 juli 2020 kl. 13.52 skrev Eli Zaretskii <eliz@gnu.org>:

> Too definitive to my palate, sorry.

Apologies -- I do my best to read your mind.

> You may wish reading the recent long discussions of what is/should be
> and what isn't/shouldn't be immutable.

Thank you, but reading it once was quite enough.

>  Turns out some of us are very
> sensitive to "should not" being used where "we recommend you not" or
> "make sure you know what you are doing" is what actually is the truth.

Very well, here is a revised proposal:

 This function does not always allocate a new string.  Callers are
 advised not rely on the result being a new string nor on it being @code{eq}
 to an existing string.

 In particular, mutating the returned value may inadvertently change another
 string, alter a constant string in the program, or even raise an error.
 To obtain a string that can be mutated, use @code{copy-sequence} on the result.