[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69387: 30.0.50; A string shouldn't be both a docstring and a return
From: |
Mattias Engdegård |
Subject: |
bug#69387: 30.0.50; A string shouldn't be both a docstring and a return value |
Date: |
Mon, 26 Feb 2024 19:04:25 +0100 |
26 feb. 2024 kl. 18.44 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> I don't understand: (cl-defgeneric FUN (ARGS) "DOCSTRING") should not
> generate a function that returns "DOCSTRING" (it should just declare
> FOO to be a generic function with no methods).
Sorry, you are quite right; there is no function generated there.
>> (defun (ARGS) "string") -> (defun (ARGS) "string" "string")
>>
>> to preserve semantics (and the same for defmacro, cl-defun, etc).
>
> I still haven't seen any code that wants this behavior, so that's
> a definite no for me.
I presume you mean that `defun`s with a single string always want it to be
their doc string? That indeed seems to be the dominant use. These are the few
counter-examples that I could find:
> (cl-defmethod gnus-search-transform ((_ gnus-search-imap)
> (_query null))
> "ALL")
> (cl-defmethod gnus-search-transform ((_engine gnus-search-notmuch)
> (_query null))
> "*")
> (cl-defmethod xref-location-group ((_ xref-bogus-location)) "(No location)")
> (defun xselect-convert-xm-special (_selection _type _value)
> "")
There is also the concern that an otherwise empty function with only a doc
string could be important for returning a non-nil value. It would take quite
some digging to find out whether that occurs so I didn't do it now.