RE: changing function signatures and no library version # => must use too-general test

[Drew Adams]

    > There is no good way to test for the function with the right
    signature,
    > AFAIK. In Emacs 22 I could use `subr-arity' to test the
    number of args,
    > which would work in this case but not in cases where the
    number was the same
    > but the parameter types were different or their order changed
    - and, anyway,
    > that would require testing whether `subr-arity' is defined,
    and, if not, it
    > would require a different test (for Emacs other than 22).

(As Davis Herrington pointed out off-list, I should have written "pre-Emacs
21" instead of "Emacs other than 22".)

    Testing with subr-arity won't work because it's not a
    subroutine, and even
    if it works it's difficult to use and inconvenient.  A better check is:

       (condition-case nil
           (help-insert-xref-button arg1 arg2 arg3)
         (wrong-number-of-arguments
          (help-insert-xref-button arg6 arg7))

Yes, I considered that.

    and interestingly, this approach can also be used when the
    number of args
    hasn't changed, as long as you can arrange for the first call to fail
    immediately (e.g. because you use some new type of argument that wasn't
    supported before).

Only if the different type in fact raises an error (as opposed to producing
incorrect results or leading to an error farther down the road).

    Of course, this is not 100% errorproof since the error you catch may
    actually come from some other piece of code within
    help-insert-xref-button.
    In many cases this is not a problem because you can be
    reasonably sure that
    having the same error signalled some other way is extremely unlikely
    (e.g. this is the case for wrong-number-of-arguments).

Yes, I agree with everything you said. It doesn't change the general
problem, however. Rather than users needing to define their own function
that does what you wrote above (if case they want to do that in multiple
places, for instance), Emacs developers should just define a new, different
function themselves (not pour new wine into old bottles).