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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Sat, 16 Mar 2024 19:32:01 UTC

Severity: normal

Found in version 30.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69832 <at> debbugs.gnu.org
Subject: bug#69832: 30.0.50; Should `subr-primitive-p` apply to special-forms?
Date: Sat, 16 Mar 2024 15:58:09 -0400
>> 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





This bug report was last modified 1 year and 63 days ago.

Previous Next


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