GNU bug report logs - #65797
`buffer-match-p` should not use `func-arity`

Previous Next

Full log

Message #85 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 07:55:32 -0400

>>>>> 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.
- 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).
- Live with the occasional breakage and bug reports like the current one.

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.