bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 69832@debbugs.gnu.org
> Date: Sat, 16 Mar 2024 19:08:56 -0400
> 
> >> - If we introduce `subr-function-p`, then `subr-primitive-p` is only
> >>   "useful" at one place any more, and we can trivially rewrite the code to
> >>   avoid it, so we could get rid of it.
> > I don't see why we should get rid of subr-primitive-p.
> 
> Because there's no point keeping it if all its users could just as well
> use `subr-function-p` or `subr-native-elisp-p` instead.
> 
> The information provided by the current semantics of `subr-primitive-p`
> is "the source code was written in C", and that kind of information is
> extremely rarely useful because ELisp code can't really act on that
> information.  The only counter example is indeed when that ELisp code is
> trying to jump to the source code.
> 
> > We can leave it alone, used in that single place where it's useful,
> > and let 3rd party packages use it if they want.
> 
> It'll mostly lead to 3rd party users either wondering which one they
> should use, or picking one arbitrarily without knowing the consequences.
> Choice is good when the various alternatives have each their own
> strengths and weaknesses, but here it's just extra complexity with no benefit.
> 
> If we introduce `subr-function-p` then we should mark `sur-primitive-p`
> as obsolete.  And the only thing we gained in the process is churn (it
> won't avoid regressions because the rare few users will likely just
> blindly replace the old one with the new one).
> 
> >> - These functions are used very rarely, the majority is in core files,
> >>   and the rest is mostly used to generate human-facing descriptions
> >>   so the risk of breakage is low and the kind of breakage is likely to
> >>   have a low impact.
> > Yes, but I've heard these famous last words one or two times too
> > many...
> 
> We make backward incompatible changes all the time in Emacs, and the
> vast majority of them turns out fine.
> 
> I searched for `subr-primitive-p` in Emacs, GNU ELPA, NonGNU ELPA, and
> Melpa before making my suggestion.

Well, you asked for opinions, and here you have mine.  I stand by it.