[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-p
From: |
Stefan Monnier |
Subject: |
bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially |
Date: |
Thu, 07 Sep 2023 11:50:16 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
retitle 65797 `buffer-match-p` should not use `func-arity`
thanks
> (match-buffers (apply-partially #'local-variable-p 'foo))
Note that this call is incorrect according to the docstring of
`buffer-match-p`, which says:
CONDITION is either:
[...]
- a predicate function that takes BUFFER-OR-NAME and ARG as
arguments, and returns non-nil if the buffer matches,
IOW, you have to pass a function that accepts 2 arguments, whereas your
(apply-partially #'local-variable-p 'foo) only accepts one.
The Texinfo docs instead say:
@item
A predicate function, which should return non-@code{nil} if the buffer
matches. If the function expects one argument, it is called with
@var{buffer-or-name} as the argument; if it expects 2 arguments, the
first argument is @var{buffer-or-name} and the second is @var{arg}
(or @code{nil} if @var{arg} is omitted).
but in general we can't reliably decide whether "the function expects
one argument", so we can't implement the above promise in a reliable way.
`apply-partially` is just one case where this shows up, but the problem
is much more general.
`buffer-match-p` uses the `func-arity` hack to try to make it work with
some functions of 1 argument, but it's just a hack.
We should get rid of this hack. Here are some possible replacements
(by order of my preference):
- Replace `&optional arg` with `&rest args` and pass those args via
`apply`, so the number of args passed doesn't depend on the function
but on the caller.
- Always pass both args to the function (i.e. as documented in the
docstring).
- Get rid of `&optional arg` altogether.
AFAICT, most callers don't use it, but it's used for
`display-buffer-alist`, so it would have further consequences there :-(
- Use a hack like
(condition-case nil (funcall condition buffer-or-name arg)
(wrong-number-of-arguments (funcall condition buffer-or-name)))
which handles the arity mismatch a bit more reliably, but at the cost of
occasionally running the function twice.
Stefan
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Joseph Turner, 2023/09/07
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Mattias EngdegÄrd, 2023/09/07
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Stefan Monnier, 2023/09/07
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially,
Stefan Monnier <=
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Joseph Turner, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Eli Zaretskii, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Stefan Monnier, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Joseph Turner, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Stefan Monnier, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Joseph Turner, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Eli Zaretskii, 2023/09/08
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Joseph Turner, 2023/09/11
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Eli Zaretskii, 2023/09/11
- bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially, Stefan Monnier, 2023/09/12