bug#46374: [External] : bug#46374: 28.0.50; Ask me to save buffers only if they are under callers dir

[Drew Adams]

> Please don't.  This will break down as soon as you
> set the function with `add-function`.
>
> [ I wish people could forget that `func-arity` exists.  
>   Its use is a bug-in-the-waiting in most cases. ]

Yeah.  But maybe Emacs Lisp can have a slightly better
function that does something like what it tries to do?

This was introduced in Emacs 26, IIUC.  It's not like
it's old cruft.  (Maybe new. ;-))

Here's what some have come up with for Common Lisp:

https://stackoverflow.com/q/15465138/729907

As long as `func-arity' exists, how about documenting
particular cases where it can likely cause trouble, or
cases where it's less likely to cause trouble, to give
users some guidance (beyond "Please don't use it")?

If it's problematic when used with things like
`add-function', is there something that can be said
about particular uses that are more or less likely to
cause trouble?  IOW, again, can we say more than just
"Don't use it"?

I'm guessing that many use cases of `func-arity' try
to sanity-test things like whether an unknown function
can accept zero args (none required), or can accept at
least one arg, etc.  If such tests are conservative
they can sometimes be more help than just testing
whether an object is `functionp'.

IOW, depend on the `func-arity' return value only in
a conservative direction; don't count on it as any
kind of guarantee that you _can_ do something, but use
it as a check that you might not want to bother to try
to do it.

An alternative for at least some use cases is to try
funcalling a function with some (possibly empty) arg
list, and see whether that raises an error.  But
sometimes that might not be what you really want to do.

Clearly, functions are essentially opaque, as data,
at least in our environment.  Still, some things can
be done, even if limited and tentative.