From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `aset` on strings, changing the size in bytes Date: Tue, 16 Oct 2018 17:05:19 -0400 Message-ID: References: <88must56x4.fsf@gnu.org> <83efe4trsa.fsf@gnu.org> <83lg8bsvfm.fsf@gnu.org> <83in3fqj9c.fsf@gnu.org> <83d0tmr97o.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1539723901 30034 195.159.176.226 (16 Oct 2018 21:05:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2018 21:05:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Noam Postavsky , rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 16 23:04:57 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCWWL-0007co-15 for ged-emacs-devel@m.gmane.org; Tue, 16 Oct 2018 23:04:53 +0200 Original-Received: from localhost ([::1]:60233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCWYR-0002iv-CO for ged-emacs-devel@m.gmane.org; Tue, 16 Oct 2018 17:07:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCWX0-0002LO-HE for emacs-devel@gnu.org; Tue, 16 Oct 2018 17:05:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCWWz-0003fd-QF for emacs-devel@gnu.org; Tue, 16 Oct 2018 17:05:34 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCWWq-0003Fg-Gk; Tue, 16 Oct 2018 17:05:26 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w9GL5J6C005150; Tue, 16 Oct 2018 17:05:20 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id CA37D6A445; Tue, 16 Oct 2018 17:05:19 -0400 (EDT) In-Reply-To: <83d0tmr97o.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Sep 2018 18:17:47 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6396=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6396> : inlines <6934> : streams <1801510> : uri <2731856> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230426 Archived-At: >> >> 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