bug#69387: 30.0.50; A string shouldn't be both a docstring and a return value

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca
> Date: Sun, 25 Feb 2024 11:29:45 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Currently, ELisp defines
> 
>     (lambda (blabla) "Help!")
> 
> as a function that returns "Help!" *and* whose docstring is "Help!".
> As seen in commit eeb89a5cb292bffe40ba7d0b0cf81f82f8452bf8, it can be
> a source of annoyance as well.
> 
> I cannot remember finding source code which makes use of this "feature".
> My impression is that our docs document this behavior simply because
> that's how it happened to work rather than how it should work.
> This is documented in the texinfo under "Function Documentation" where
> it says:
> 
>     [...
>     effects, it has no effect if it is not the last form in the body.  Thus,
>     in practice, there is no confusion between the first form of the body
>     and the documentation string; if the only body form is a string then it
>     serves both as the return value and as the documentation.
> 
> I think we should change that to say that
> 
>     if the only body form is a string then it serves as the return value
>     and not as the documentation.
> 
> This will/would require a few changes to `macroexp.el` and
> `bytecomp.el`, but it should be minor.  It shouldn't introduce any
> significant breakage either because the only effect will be to make it
> so some functions won't have a docstring any more, but most (all?) of
> those function never expected to have a docstring in the first place.

Here again we are changing age-old (mis)features, which some code
somewhere probably relies upon.  Why? because a newly-introduced
byte-compilation warning erroneously flagged that as a mistake in the
doc string.

My vote is to leave this alone.