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: [PATCH] * etc/NEWS: Document incompatibilities introduced by record types. Date: Tue, 12 Dec 2017 20:29:18 -0500 Message-ID: References: <20171211213729.41411-1-phst@google.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513128582 22039 195.159.176.226 (13 Dec 2017 01:29:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Dec 2017 01:29:42 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 13 02:29:33 2017 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 1eOvrY-0005Ki-UC for ged-emacs-devel@m.gmane.org; Wed, 13 Dec 2017 02:29:33 +0100 Original-Received: from localhost ([::1]:33069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOvrf-0000Mc-NV for ged-emacs-devel@m.gmane.org; Tue, 12 Dec 2017 20:29:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOvrZ-0000MM-Ej for emacs-devel@gnu.org; Tue, 12 Dec 2017 20:29:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOvrW-0004mr-C2 for emacs-devel@gnu.org; Tue, 12 Dec 2017 20:29:33 -0500 Original-Received: from [195.159.176.226] (port=54307 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eOvrW-0004mO-4b for emacs-devel@gnu.org; Tue, 12 Dec 2017 20:29:30 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eOvrM-0004pS-Sf for emacs-devel@gnu.org; Wed, 13 Dec 2017 02:29:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 25 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:O2aD+dfFKrT1uknhYFUyXptjOrg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:220982 Archived-At: > I thought you already agreed we should make "define an 'integer' > struct" an error, why are we still arguing about this? I agreed that it's OK to introduce such a check but that doesn't mean I think we *should* have such a check. I'm just really puzzled by all the strong reactions for a problem that's so% hypothetical, and really very similar to lots of other "risks" that we don't care about at all. Maybe it's just because it's brand new, whereas the other risks have been with us for so many years that we completely forgot about them? Stefan PS: By the way, feel free to try to (cl-defstruct integer ...) and play with it. From what I can tell, it takes dedication to go from there to actually experiencing an undesirable outcome. If you want to shoot yourself in the foot (add-hook 'post-command-hook #'beginning-of-buffer) is a much safer choice (and as bonus, it doesn't require cl-lib),