suggestion on adding arguments to existing functions

suggestion on adding arguments to existing functions

[Drew Adams]

I don't want to start a war on this, but I'd like to make a suggestion wrt
the general procedure of adding arguments to existing functions. It's
possible that I'm missing something - if so, that might be good to discuss,
but otherwise, please just take this suggestion into consideration.

Here's an example of a function signature in Emacs 20 and in Emacs 21:

(dabbrev--substitute-expansion old abbrev expansion)

(dabbrev--substitute-expansion old abbrev expansion record-case-pattern)

The library that uses this function, dabbrev.el, only calls it in two
places, one of which uses the value nil (which is equivalent to using the
old form).

My suggestion is to use `&optional' in a case like this, other things being
equal (that is, if there is no good reason not to). Why? Because otherwise
it unnecessarily breaks libraries that use the old form and (more
importantly, to me) libraries that try to work with multiple versions of
Emacs. It makes those libraries use ugly constructs such as this (or a macro
that does the same thing):

(if (< emacs-major-version 21)
    (dabbrev--substitute-expansion nil abbrev init)
  (dabbrev--substitute-expansion nil abbrev init nil))

Not only is that unnecessarily ugly, but, in the general case, it means
needing to examine various Emacs versions to find out exactly when the arity
was changed (to get the version test right).

[Now, if there were a function that we could use to test the arity, that
would also be welcome here (a version test is not the first choice, if there
is an alternative). In Emacs 21 and 22 there is `sub-arity', but that only
works for built-in functions, IIUC.]

Why "unnecessarily"? Because if the function were extended with `&optional'
then there would be nothing to do. (Even the changes to Emacs itself would
be easier - in this case, one of the two calls would not need to change, and
that's the average case for a binary value: 50%.)

This example involves a change made between Emacs 20 and 21, but the
suggestion is general and concerns only future changes - it's just something
you might keep in mind.

I understand that backward compatibility is not a priority for Emacs
developers. Nevertheless, if there is no good reason not to take code
evolution into account in a given case (e.g. if there is no added cost in
performance, clarity, development, maintenance,...), then why not do so?

Thanks for thinking it over.

Re: suggestion on adding arguments to existing functions

[Richard M. Stallman]

    My suggestion is to use `&optional' in a case like this, other things being
    equal (that is, if there is no good reason not to). Why? Because otherwise
    it unnecessarily breaks libraries that use the old form and (more
    importantly, to me) libraries that try to work with multiple versions of
    Emacs. It makes those libraries use ugly constructs such as this (or a macro
    that does the same thing):

That's a good argument for functions that were meant for users to
call, but we need not worry about it for internal functions.  Users
must be prepared for their calling conventions to change.

    [Now, if there were a function that we could use to test the arity, that
    would also be welcome here (a version test is not the first choice, if there
    is an alternative). In Emacs 21 and 22 there is `sub-arity', but that only
    works for built-in functions, IIUC.]

That would be a good feature to add, after the release.
I will add it to etc/TODO, but let's not discuss it now.