From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 2bb0703 1/2: lisp/*.el: Force non-nil result to t, to match docstring Date: Thu, 17 Oct 2019 14:02:49 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77535"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , Lars Ingebrigtsen , Drew Adams , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 17 20:03:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iLA7A-000K18-Hx for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 20:03:08 +0200 Original-Received: from localhost ([::1]:55656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLA78-0007GW-Ks for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 14:03:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56308) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLA6y-0007GG-9i for emacs-devel@gnu.org; Thu, 17 Oct 2019 14:02:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLA6w-00033n-G8 for emacs-devel@gnu.org; Thu, 17 Oct 2019 14:02:55 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3103) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iLA6u-000324-SP; Thu, 17 Oct 2019 14:02:53 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 06D904490C6; Thu, 17 Oct 2019 14:02:52 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 882BD4490B1; Thu, 17 Oct 2019 14:02:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1571335370; bh=4Iv6Wmvp0ye6jG+0X5csBckT8/grTPHZbJRF88wwu78=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=SFyASD0KKX/65SitAQ6uUFuAxGFCW1sUzdnMoa/yi/QRx5rDVJVlcIe2138+bDs1q 9YeUvj27tA345ftk1bLdeYTiS95lk0De/oLa2HL2RVCQ3kfdmYb9jJgTMkVPNRy/mU JlHCtmwA6hvbziJbHipSNdDIyXNwAs1RH4HIKs6Qhf8piFqql78KIltGm43KN1czL6 QfQjwbQbuaXS6OF+fsw4YSe1USpwfIB22UjuzfkTsEgUzX9VP/mVfDcnUOboew53XB i67yFs8+52TPzCQ4F+Yqek4ZOI6r9G1EeFY4aVnlP49cLPBkl8ntx5Fkv6QUqk57m8 m7yKO2SRjC3eg== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 69CFF120DAC; Thu, 17 Oct 2019 14:02:50 -0400 (EDT) In-Reply-To: (Juanma Barranquero's message of "Thu, 17 Oct 2019 17:43:36 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:241160 Archived-At: Just to be clear: this is a typical bikeshed subject. Some people think functions that return booleans should return nil/t and other think they should return nil/non-nil. It's a question of opinion. There are advantages on both sides. So far, AFAIK most of the code and docstrings use nil/non-nil, AFAICT (which is why we're all familiar with the notion of "non-nil" as a matter of fact) and as a maintainer I've made an effort to try and standardize on this, e.g. by fixing docstrings which overspecified the return value to `t`. This is similar to the issue of documenting side-effecting function's return value versus discouraging the use of their return value. The most important thing is to try and choose one and stick to it, both for the benefit of consistency and to avoid back-and-forth cosmetic changes. Stefan Juanma Barranquero writes: > The issue here is not transforming every "predicate" -p function into one > returning t/nil. That's not what my patches did. And in my original answer > I already said that most predicates return t/nil, but not *all*. I would > contend that "predicates" not returning t/nil aren't really predicates, but > that's a discussion for another day. > > Most of my latest patches make the function follow its documented interface > (the docstring), which shouldn't be so controversial. In fact, if some > function relied on the documented t result, if was risking getting > something different, often in obscure cases. So I'd say this patch will > help uncover bugs. (I'd be surprised that a function, for example, > documented as "return t", returning a marker in *some* cases, is being used > purposely so by the client code.) > > In other cases, they fix problems; either because the docstring says that > it returns t, but in fact they return a useful non-nil value, or because > the functions say non-nil/nil, but are in fact functions that, but it's > very nature, will always return only t/nil. That shouldn't be > controversial, either. > > I mean, if some specific change in my patches is a mistake, let's discuss > it or fix it. But mostly, what I've done is fixing latent bugs, either in > the documentation or the code.