From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#69387: 30.0.50; A string shouldn't be both a docstring and a return value Date: Mon, 26 Feb 2024 18:15:36 +0100 Message-ID: <2D08AD76-59F7-41BE-9363-96677967034A@gmail.com> References: Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , Eli Zaretskii , 69387@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 26 18:18:17 2024 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 1reecK-0004z4-CM for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Feb 2024 18:18:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1reebj-0003sQ-FC; Mon, 26 Feb 2024 12:17:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reebh-0003rf-IX for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 12:17:37 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1reebh-0003dT-An for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 12:17:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1reec6-00023h-92 for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 12:18:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Feb 2024 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69387 X-GNU-PR-Package: emacs Original-Received: via spool by 69387-submit@debbugs.gnu.org id=B69387.17089678317792 (code B ref 69387); Mon, 26 Feb 2024 17:18:02 +0000 Original-Received: (at 69387) by debbugs.gnu.org; 26 Feb 2024 17:17:11 +0000 Original-Received: from localhost ([127.0.0.1]:50467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reebG-00021b-VH for submit@debbugs.gnu.org; Mon, 26 Feb 2024 12:17:11 -0500 Original-Received: from mail-lf1-f41.google.com ([209.85.167.41]:52475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reebF-00021I-IS for 69387@debbugs.gnu.org; Mon, 26 Feb 2024 12:17:10 -0500 Original-Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-512d19e2cb8so4955810e87.0 for <69387@debbugs.gnu.org>; Mon, 26 Feb 2024 09:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708967738; x=1709572538; darn=debbugs.gnu.org; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=jZ+bn2QBUyHaSxG+DReP64Ue/T8xW10rWHjSt0rcmdw=; b=hUS9uPhStRHWiJQ5KH6aMU54wezBW3wxd9nTr/kLUGrrGV7hEpCEyaeFMk7o75UCbr 8fz+Anfmi3eZZ26DrYtRe3t2VGcfTsPiUVn00kKXNy4UvKvKlfud5i2FbgGRdsPHD7fX LBRlnYoGb3Q64CSCTn2fPpBjYEp6hMeRwiTD2YQB5BRmvI0OpUsdOy5+bDLm1IQhxsl9 +II1O6wqugJPh+DNG5pFOH85bYNXnc5DDWv+Pza/BUU6tNEYYwBIN01M5sxNtc8XTYq1 fAs9yIccCGupeVu/68ACd12dvTOeRJf5mVmNiw6rnj7wt4Nc+uc+DOmoEB56JsobAdgk DCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708967738; x=1709572538; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jZ+bn2QBUyHaSxG+DReP64Ue/T8xW10rWHjSt0rcmdw=; b=lum0i6I1Ckws4R3ZnLfJJLnKo65qv3xZUZFUTn+opwEmEAvAtQ+uVqGnQK9E/qRZGM 3nOO3Bs9EIN0ii3YTTI4LCMP9EXc0slSaTb2w+M8RNpHrzLy/t33HlJb+gRe7dgl7cVU m+XgjWN2qsYbotrU6k0r/MPMmS70QTEbAuBdfQkFGCI3pynib5JgRNXZg1R0lhRL7+19 4Of9rabi3/vFd9PmNVwNHl7eoBn/mBlyKw1QUrqIz2rie2tFZtlDbq+BtVaXQ7PxX1At al1JAb62FXgDMnDApDamtuIXZKDeloNtIa9ryuM9VJrnPinLaMb2A2PdsFLJFASjn382 iqow== X-Forwarded-Encrypted: i=1; AJvYcCX5lFvVjJfEyYEZLDHCYu0hdCtzie/2dhOdngeMiKSddqdyZte7rQ9Bv3vWvbabCuDP1rA7tlIOHhSUkAfHjeX130SKPYk= X-Gm-Message-State: AOJu0Yw7Sb3nszIgNcU92WOxd3KD0C1mBu4fqZqZAtBsXOQWM/JrgRwm 941HpP18sT8Dl+dujDnAOfFS/KhNALjge5qSiaSO4Lw3kqbZLlaO X-Google-Smtp-Source: AGHT+IFGq18SwUOB5Q2pp6hZE9eGhoAA5SZQNvRmIF1RtrksluMsGJFn2e5pxo+X2ZX4pIihUiaCVg== X-Received: by 2002:a05:6512:3762:b0:512:dc10:a955 with SMTP id z2-20020a056512376200b00512dc10a955mr4350110lft.26.1708967737801; Mon, 26 Feb 2024 09:15:37 -0800 (PST) Original-Received: from smtpclient.apple (c80-217-1-132.bredband.tele2.se. [80.217.1.132]) by smtp.gmail.com with ESMTPSA id m6-20020a194346000000b0051300df1f53sm222205lfj.214.2024.02.26.09.15.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2024 09:15:37 -0800 (PST) X-Mailer: Apple Mail (2.3654.120.0.1.15) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280693 Archived-At: > There is no benefit to this misfeature. > Leaving this alone will maintain a low-level of pain for the > foreseeable future. Fixing it may introduce minor breakage (like > `C-h m` saying there's no docstring) in the short term but these are > easy to fix and they'll disappear quickly. Indeed. Eli is right that we need to be careful, but a mechanised scan = of our code really shows that this might be a source of bugs that we = should consider doing something about. An amusing example: > (defun semantic-mrub-read-history nil > "History of `semantic-mrub-completing-read'.") ... which is then not called but used as a variable by the code. Or this one: > ;; Don't alias this to `ignore', as that will cause the resulting > ;; function to be interactive. > (defun use-package-normalize/:disabled (_name _keyword _arg) > "Do nothing, return nil.") Return nil my foot. Would it be productive to warn, and about what? Not for pure lambdas, = because there should be nothing wrong with (lambda () "string") and it's extremely unlikely to be intended as a doc string (I found not = a single instance). The overwhelming majority of docstring-value `defun`s are functions that = are placeholders, unfinished or unimplemented, sometimes with = commented-out code. Often it's clear that the user didn't know how to = proceed: This indicates that maybe we should warn for `defun`; users can easily = add a `nil` before or (more commonly) after the string depending on what = they mean. The docstring-result syndrome is particularly common in `cl-defgeneric` = because it's not seen as code that will ever be used, so we should = probably not warn in that case. We could expand (defun (ARGS) "string") -> (defun (ARGS) "string" "string") to preserve semantics (and the same for defmacro, cl-defun, etc).