[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35433: 27.0.50; 'function' docstring: tell more about advantages?
From: |
Eli Zaretskii |
Subject: |
bug#35433: 27.0.50; 'function' docstring: tell more about advantages? |
Date: |
Thu, 23 May 2019 21:31:45 +0300 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 35433@debbugs.gnu.org
> Date: Thu, 23 May 2019 18:55:08 +0200
>
> > I'd say "... will warn if that function is not defined, which means
> > it might not be known at run time" instead.
>
> No, these are two different cases: (1) function not known when
> compiling, and (2) known to the compiler but function may still be
> unknown when the compiled code is run, because the compiled file misses
> `require' statements, for example.
Then replace "which means it" with "or".
> > "Undefined" and "unknown" sound vague and more ominous to me.
>
> Well, I tried to reuse the words from the actual compiler warnings - see
> `byte-compile-warn-about-unresolved-functions'.
The warnings there say
"the function `%s' might not be defined at runtime."
"the function `%s' is not known to be defined."
They don't say "undefined" and "unknown".
> I may change "may be unknown" to "may not be known" - unless you
> have a better idea:
>
> +When @var{function-object} is a symbol and the code is byte compiled,
> +the byte-compiler will warn should that function be undefined or may
> +not be known at run-time.
The phrase "should that function be ..." is usually interpreted as
something that may or may happen in the future, which AFAIU is not
what you mean. That's why I proposed a different wording, which
doesn't have that problem. Or maybe I'm misunderstanding your intent.