Subject: bug#71123: [PATCH] Rename `subr-native-elisp` to `native-comp-function`

From: Andrea Corallo <[email-masked]>
Date: Fri, 24 May 2024 03:17:30 -0400

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[email-masked]> writes:

> Tags: patch
>
> I can't remember where someone requested a nicer name than
> `subr-native-elisp`, but here's a patch which aims to do that.
>
> AFAICT we do not need to preserve the *type* `subr-native-elisp` because
> it was never exposed to ELisp before Emacs-30 anyway.  So the only
> backward compatibility needed is the `subr-native-elisp-p` function.
>
> I chose `native-comp-function` as the new name based on a few
> `grep`s through our C code which suggested that `native-comp-` is the
> most "popular" prefix in there from code related to native compilation.
>
> I don't have a strong preference, so if there's a consensus around
> another name, I'll happily change the patch accordingly.

Hi Stefan,

I don't have a strong opinion about renaming this, at the time I called
it subr- something as in my mind it was really a subr from an ABI stand
point of view.  So yeah my implementor view was probably biased
technically.

For this reason I'm not opposed to this change but I'd like to hear
Eli's opinion.

On the patch itself I've three comments:

- If we go for it, shouldn't we rename SUBR_NATIVE_COMPILEDP and
  SUBR_NATIVE_COMPILED_DYNP macros as well for consistency?

- The patch introduces a number of warnings in: help-fns.el, subr.el,
  bytecomp.el, comp.el, comp-common.el.

- It's also introducing a fail in lisp/help-fns-tests.log

Thanks

  Andrea