policy regarding DEFUNs in subr-x.el

policy regarding DEFUNs in subr-x.el

[Štěpán Němec]

When fixing bug#39980 [1], it seemed best to me to move a string utility
function to subr-x. Given the file's commentary (notably "NB If you want
to use this library, it's almost always correct to use:
(eval-when-compile (require 'subr-x))") and the fact that with a single
outlier of `replace-region-contents', everything in that file is either
inline functions or macros, I turned the added function into defsubst,
which seems to have raised Lars's eyebrows, and Eli's, probably, too.

Now, it does seem sensible for the function to be a normal, not inline,
function, but what about the commentary and all the other defsubsts,
including the other string utilities?

If the no-defun policy should be changed, or if I was mistaken in
believing there was one to begin with, shouldn't the commentary
recommending compile-time usage be removed, and at least some of the
other defsubsts turned into defuns, too?

Any clarification would be much appreciated.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-03/msg00643.html

-- 
Štěpán

Re: policy regarding DEFUNs in subr-x.el

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@gmail.com>
> Date: Sun, 22 Mar 2020 16:46:36 +0100
> 
> Now, it does seem sensible for the function to be a normal, not inline,
> function, but what about the commentary and all the other defsubsts,
> including the other string utilities?
> 
> If the no-defun policy should be changed, or if I was mistaken in
> believing there was one to begin with, shouldn't the commentary
> recommending compile-time usage be removed, and at least some of the
> other defsubsts turned into defuns, too?

I don't see that the commentary says the code in this file must be
inline.  If something in the wording implies that, let's change the
wording so that it doesn't.

From my POV, there's no reason to require that everything in that file
is inlined, and that single "outlier" is the evidence.

Re: policy regarding DEFUNs in subr-x.el

[Tassilo Horn]

Didn't we decide that replace-region-contents is to be moved to replace.el? Sorry, I didn't follow that past discussion/patch closely but from my pov that would make sense, and given that this function is new in emacs 27, now is the best time doing so.

Bye,
Tassilo

Am So, 22. Mär 2020, um 18:12, schrieb Eli Zaretskii:
> > From: Štěpán Němec <stepnem@gmail.com>
> > Date: Sun, 22 Mar 2020 16:46:36 +0100
> > 
> > Now, it does seem sensible for the function to be a normal, not inline,
> > function, but what about the commentary and all the other defsubsts,
> > including the other string utilities?
> > 
> > If the no-defun policy should be changed, or if I was mistaken in
> > believing there was one to begin with, shouldn't the commentary
> > recommending compile-time usage be removed, and at least some of the
> > other defsubsts turned into defuns, too?
> 
> I don't see that the commentary says the code in this file must be
> inline.  If something in the wording implies that, let's change the
> wording so that it doesn't.
> 
> From my POV, there's no reason to require that everything in that file
> is inlined, and that single "outlier" is the evidence.
> 
> 
>

Re: policy regarding DEFUNs in subr-x.el

[Štěpán Němec]

On Sun, 22 Mar 2020 19:12:43 +0200
Eli Zaretskii wrote:

>> If the no-defun policy should be changed, or if I was mistaken in
>> believing there was one to begin with, shouldn't the commentary
>> recommending compile-time usage be removed, and at least some of the
>> other defsubsts turned into defuns, too?
>
> I don't see that the commentary says the code in this file must be
> inline.  If something in the wording implies that, let's change the
> wording so that it doesn't.

Thank you. In that case I suggest we remove the NB sentence, as IMO it
adds more confusion than useful information.

-- 
Štěpán

Re: policy regarding DEFUNs in subr-x.el

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 28 Mar 2020 15:20:52 +0100
> 
> > I don't see that the commentary says the code in this file must be
> > inline.  If something in the wording implies that, let's change the
> > wording so that it doesn't.
> 
> Thank you. In that case I suggest we remove the NB sentence, as IMO it
> adds more confusion than useful information.

How about if instead of removing, we reword it so that it only talks
about the macros in the file?

Re: policy regarding DEFUNs in subr-x.el

[Štěpán Němec]

On Sat, 28 Mar 2020 17:35:39 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 28 Mar 2020 15:20:52 +0100
>> 
>> > I don't see that the commentary says the code in this file must be
>> > inline.  If something in the wording implies that, let's change the
>> > wording so that it doesn't.
>> 
>> Thank you. In that case I suggest we remove the NB sentence, as IMO it
>> adds more confusion than useful information.
>
> How about if instead of removing, we reword it so that it only talks
> about the macros in the file?

IMHO that would still beg the question "what's so special about this
library that they're talking about this?", thus if not confusion, at
least still a distraction. I don't think the fact that you can `require'
libraries at compile time only (i.e. wrapped in `eval-when-compile'), as
long as you only use macros or inline functions from those libraries,
needs special mention?

-- 
Štěpán

Re: policy regarding DEFUNs in subr-x.el

[Štěpán Němec]

On Sat, 28 Mar 2020 15:47:11 +0100
Štěpán Němec wrote:

>> How about if instead of removing, we reword it so that it only talks
>> about the macros in the file?
>
> IMHO that would still beg the question "what's so special about this
> library that they're talking about this?", thus if not confusion, at
> least still a distraction. I don't think the fact that you can `require'
> libraries at compile time only (i.e. wrapped in `eval-when-compile'), as
> long as you only use macros or inline functions from those libraries,
> needs special mention?
        ^^^^^^^^^^^^^^^

(Just to be completely clear: I meant special mention in every file
concerned. I believe it _is_ mentioned in the manuals.)

-- 
Štěpán

Re: policy regarding DEFUNs in subr-x.el

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@gmail.com>
> Date: Sat, 28 Mar 2020 15:47:11 +0100
> Cc: emacs-devel@gnu.org
> 
> > How about if instead of removing, we reword it so that it only talks
> > about the macros in the file?
> 
> IMHO that would still beg the question "what's so special about this
> library that they're talking about this?"

It's "special" of sorts, in that it's mostly macros.

Re: policy regarding DEFUNs in subr-x.el

[Štěpán Němec]

On Sat, 28 Mar 2020 18:04:40 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@gmail.com>
>> Date: Sat, 28 Mar 2020 15:47:11 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> > How about if instead of removing, we reword it so that it only talks
>> > about the macros in the file?
>> 
>> IMHO that would still beg the question "what's so special about this
>> library that they're talking about this?"
>
> It's "special" of sorts, in that it's mostly macros.

:-D Yes, but not only macros, so you'd have to say something like "if
you only need macros (and inline functions) from this library (and
byte-compile your code), you can do (eval-when-compile ...)", which
could be said about a lot of other libraries as well.

But yes, it would at least be less confusing than the current wording,
so if you don't want to remove the note, it would be an improvement I
think.

-- 
Štěpán

Re: policy regarding DEFUNs in subr-x.el

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 28 Mar 2020 16:31:12 +0100
> 
> But yes, it would at least be less confusing than the current wording,
> so if you don't want to remove the note, it would be an improvement I
> think.

Thanks, let's see what others think about this.