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

[Stefan Monnier]

>> I can see two ways to fix that:
>> 
>> - Introduce a new type, says `subr-function(-p)` which returns non-nil
>>   if and only if the argument is a built-in primitive *and* a function.
>> 
>> - Change the implementation of `subr-primitive-p` to match its docstring.
>> 
>> The patch below does the second (including changing the only place
>> I found that wants the current semantics.
>> 
>> Comments?  Objections?
>
> Why take the path of a breaking change instead of the non-breaking
> alternative?

- It can be considered as a bug fix (to make the code match its doc).

- 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.

- 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.


        Stefan