From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not Date: Mon, 05 Jul 2021 16:34:58 -0400 Message-ID: References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22155"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org To: Philipp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 05 22:36:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0VK5-0005Zb-Ur for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 22:36:09 +0200 Original-Received: from localhost ([::1]:55866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0VK4-0008Qh-Ve for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 16:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41158) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0VJy-0008QU-Ot for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:36:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35199) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m0VJy-0001Xk-Gu for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m0VJy-0007yl-5x for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jul 2021 20:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43557 X-GNU-PR-Package: emacs Original-Received: via spool by 43557-submit@debbugs.gnu.org id=B43557.162551730930608 (code B ref 43557); Mon, 05 Jul 2021 20:36:02 +0000 Original-Received: (at 43557) by debbugs.gnu.org; 5 Jul 2021 20:35:09 +0000 Original-Received: from localhost ([127.0.0.1]:46745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0VJ6-0007xc-Pm for submit@debbugs.gnu.org; Mon, 05 Jul 2021 16:35:09 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0VJ5-0007x2-0X for 43557@debbugs.gnu.org; Mon, 05 Jul 2021 16:35:07 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CE0F0100104; Mon, 5 Jul 2021 16:35:00 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 60CFE100006; Mon, 5 Jul 2021 16:34:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1625517299; bh=8YOgucCVKRM5A0FJKPysDj68T5+qnr7pTaKJI6j6FC0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OPknfUjhkHLlzfvReyypg6CHfbqdYAcaZWU9Oq6udjA2h6DGdMs6KHJLJI/Kh1/er +PIuqjeB0vfVhVtauB33yK6wUfGlRD8Cm4fSUUnL+iAAEE3Ml6yj5dWfH06kUxtVPH V7NoXoDuZHigpUTljsZ9GUfi9JbbIEEtmvM5WOIWQAk33FTV6HPfn1GuteIM7nAQEg giABNRjZVjghA8GkAbv6ED3jRmuBI4vzs6+fymDEvVQVW4vjx+uFZmsuDFGXIaJcPq ilmMdr667ru5NeOS0x/sjsnZUnfaon12czHgxvrhhYWep9iE9sYIN6YU4u3vc+JgKw JFT9Zk4AJGwIw== Original-Received: from alfajor (unknown [45.72.205.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3282012033E; Mon, 5 Jul 2021 16:34:59 -0400 (EDT) In-Reply-To: (Philipp's message of "Mon, 5 Jul 2021 20:55:05 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209491 Archived-At: >> but I'd say that using `setcar` above is risky because the user has >> no guarantee about what it may impact. > I think that a word like "risky" has no place in a reference manual. It doesn't have its place in the part that describes technically the effect of the operation. It can have its place in the part that gives recommendations for style and recommended practices. > What does that even mean? What are the risks? That the effect goes further than the author anticipated. > Why introduce such vague and confusing terminology to begin with? In the hope of saving them (and/or others) some serious head scratching, and more generally in the hope to improve the reliability of ELisp code out there. >> I think the rule is basically, that you should only ever use `setc[ad]r` >> on cons cells you yourself created. > What does "should" mean here? It's here a recommendation and a request. > What happens if users don't follow this "recommendation"? Experience teaches us that when a piece of code uses `setcar` on a cons-cell built by some "unrelated" piece of code, there's a high probability that sooner or later the `setcar` will end up modifying more data than intended (because that same cons cell is shared with some other "unrelated" data structure). I.e. you get a bug; one that can take a fair bit of effort to track down. > How do they identify "cons cells you yourself created"? When in doubt, assume that it's not "a cons cells you yourself created". > Again, I think such terminology brings up more questions than it answers. Agreed. Mutation is pretty nasty, indeed. >> But indeed the manual fails to document which functions guarantee to >> return "fresh" new cells, which makes it hard to know which cells >> "you yourself created". > Then let's document that (while avoiding terms such as "you yourself created"). I'd welcome that, yes. > Can we find a wording that we agree on and put it into the manual? I can't think of a reason why not. Stefan