Re: Inferred function types in the *Help* buffer

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

1 juni 2023 kl. 13.50 skrev Andrea Corallo <acorallo@gnu.org>:

> if something will prove not to
> be correct we'll just fix it as we do for everything else.

I think the general idea is fine. What I meant was that some type specifications can be more of a hindrance than help, in the same way that we in some docstrings prefer to override the automatically generated argument signature -- for better precision, or to avoid confusing the user with technicalities or obsolete arguments.

There may also be a problem of inaccuracy, and here is a little anecdote. I needed a table of boolean functions that only return nil or t for the byte-compiler, so I tried to use comp-known-type-specifiers.

Either I misunderstood what a return value of `boolean` means, or that list is riddled with errors. The following functions are specified to return boolean in comp-known-type-specifiers but actually may return other values as well:

  proper-list-p
  buffer-modified-p
  coordinates-in-window-p
  custom-variable-p
  file-locked-p
  file-symlink-p
  frame-visible-p
  framep

and, since we have no guarantees about what file handlers actually return,

  file-directory-p
  file-exists-p
  file-newer-than-file-p
  file-readable-p
  file-writable-p

This is just from a quick survey of a small subset of comp-known-type-specifiers, which means that it is difficult to trust in its current state. It can all be corrected but it is slow and tedious work.