bug#65797: `buffer-match-p` should not use `func-arity`

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>>> FWIW The intention here was to be able and specify simpler conditions
>>>>>> that don't have to handle the alist.
>>>>> You mean for `display-buffer-alist`?
>>>>> Do you have examples that rely on this?
>>>> From the core?  No, I cannot think of an example, but any user
>>>> configuration may make use of this feature.
>>> From the core would have been good, but from elsewhere (including
>>> random .emacs config you may find on the web) would be helpful to gauge
>>> how important that could be.
>> I don't know of any examples.
>
> In that case I suggest we deprecate this feature (i.e. the fact that
> the function can take a single arg).
>
>>>> I am not sure if I just missed it, but is there no technical solution
>>>> around the advice issue?  Couldn't `func-arity' check if the actual
>>>> function and the advice function have the same arity, and return the
>>>> right value in that case?  My impression is that in 99% of the cases,
>>>> advice isn't used to increase or decrease the arity of a function.
>>> There are various 99% solutions, yes.
>>> There is no 100% solution, OTOH :-(
>>> So the documented behavior is inherently unreliable.
>> So what are the options then?
>
> Alternatives I can see:
>
> - Deprecate the feature with no replacement (i.e. users will have
>   to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
>   were using the feature).  That's my favorite option at this point.

I would be disappointed to see this path taken, since part of my hope
with buffer-match-p was that it could be used in project.el as well
(allowing this to be a thing is one of the reasons I started working on
Compat).

> - Replace it with some alternative (e.g. provide two different syntaxes
>   for functions, one for functions that expect all args and one for
>   functions that only take a single arg).

So `(arg1 ,(lambda (x) ...)) and `(arg2 ,(lambda (x y) ...))?  Or only
one, and otherwise we assume that the function can be invoked with a
single/two arguments?

> - Live with the occasional breakage and bug reports like the current one.

The issue here was related to advising a function.  And you are saying
there is no way around this, not even by annotating the function symbol
with the initial arity before it is advised.

>> Does one have to pick a 99% solution?
>
> Hopefully not.  The 99% solution (whichever one is used) should
> hopefully only be used temporarily for backward compatibility while the
> feature is phased out.
>
>
>         Stefan
>

-- 
Philip Kaludercic