GNU bug report logs - #42296
27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: mattiase <at> acm.org
Cc: 42296 <at> debbugs.gnu.org
Subject: bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]
Date: Thu, 09 Jul 2020 22:20:20 +0300

> Date: Thu, 09 Jul 2020 21:51:19 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 42296 <at> debbugs.gnu.org
> 
> That's not really what I asked for.
> 
> And how does mutability enter the picture?  We could say something
> about it (but then we'd have to be less terse), but that doesn't in
> any way replace the need to say that in many cases the value will be a
> new string, IMO.

Here's what I had in mind:

  This function frequently, but not always, constructs a new string
  that is not @code{eq} to any existing string.  Lisp programs should
  not rely on the result being a new string nor on it being @code{eq}
  to an existing string.

  When this function returns a string @code{eq] to another, changing
  the result will also change that other string; to avoid that, use
  @code{copy-sequence} on the result.

WDYT?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.