[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: |
Stefan Monnier |
Subject: |
bug#69387: 30.0.50; A string shouldn't be both a docstring and a return value |
Date: |
Mon, 26 Feb 2024 13:17:25 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>>> (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:
No, I mean that we should not keep the old dual-use semantics, even if
it means some docstrings get temporarily "lost" until the code is fixed.
As for whether (defun (ARGS) "string") should treat the string as
a docstring or a return value, I'd rather keep it as a return value, so
it's the same as for `lambda`. Another reason is because, the kind of
failures it is likely to introduce is a lot more mild: it's much safer
to remove a docstring than to change the return value.
So far, the harder part of such a change (beside getting it accepted đ)
seems to be the font-lock highlighting.
Stefan