From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Change in files.el Date: Sat, 28 Jan 2017 19:53:25 +0200 Message-ID: <83wpdfxe96.fsf@gnu.org> References: <83mvebzh0k.fsf@gnu.org> <83bmurz0y9.fsf@gnu.org> <8360kzyxor.fsf@gnu.org> <83ziibxg7j.fsf@gnu.org> <83y3xvxfbs.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485626078 28586 195.159.176.226 (28 Jan 2017 17:54:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Jan 2017 17:54:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 28 18:54: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 1cXXCW-0005QC-Fr for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 18:54:12 +0100 Original-Received: from localhost ([::1]:52707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXXCb-0003pI-Vo for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 12:54:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXXBy-0003p1-KT for emacs-devel@gnu.org; Sat, 28 Jan 2017 12:53:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cXXBt-0001SZ-PW for emacs-devel@gnu.org; Sat, 28 Jan 2017 12:53:38 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXXBt-0001SV-MA; Sat, 28 Jan 2017 12:53:33 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2359 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cXXBs-0004e3-SB; Sat, 28 Jan 2017 12:53:33 -0500 In-reply-to: (message from Stefan Monnier on Sat, 28 Jan 2017 12:42:22 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:211707 Archived-At: > From: Stefan Monnier > Date: Sat, 28 Jan 2017 12:42:22 -0500 > > > The issue is not serious enough to prevent people from using the > > methods you'd like to see, but I question the wisdom of having a > > project-wide guidelines to _always_ use them is similar situations. > > I think the benefits are the following: > - (eventually) more consistency, such as knowing that you can use > `add-function` will work right on any *-predicate or > *-function variable. > - until recently, it was common for such variables to have a nil > default value. Without an active effort to reverse this, we'll always > end up with such new variables introduced with a nil default value > (especially since it's very common for new such variables to have > a trivial default behavior, and only accumulating complexity later > on, at which point it's a lot more difficult to change the default to > be non-nil). I'm saying that the benefits do not necessarily outweigh the downsides, at least IME. And since the goal of having this consistently everywhere is not really achievable in practice, given our development and maintenance procedures, we are buying disadvantages on account of an advantage that will never materialize.