RE: Arbitrary function: find the number(s) of expected arguments

[Drew Adams <drew.adams@oracle.com>]

> > >  `subr-arity' is still in the documentation, but I replaced its
> > > description with an advice to use `func-arity' instead.
> >
> > Again, that is wrong, IMO.
> 
> It isn't.

It is, IMO.

> > IIUC, you _cannot_ use `func-arity' to test whether something
> > is a subr.
> 
> You have subrp for that; using subr-arity for this purpose borders
> on the ridiculous.  It's certainly unclean.

Doesn't matter.  The doc string of `subr-arity' should be faithful
to what it does.  Unless we deprecate it in favor of `func-arity',
it is incorrect to pretend that the doc for `func-arity' describes
the behavior of `subr-arity'.

I never said that one should use `subr-arity' in place of `subrp'.
I said only that `func-arity' does not give you the behavior of
`subr-arity'.  The doc for the latter should say what it does.

> > IOW, I am repeating the same argument I made before, when
> > I said that `subr-arity' should not be deprecated and
> > simply replaced by `func-arity'.
> 
> You were wrong then, and you are wrong now.

You were wrong then, and you are wrong now.  Naahhh.

Deprecate `subr-arity' and there will be no problem with having
the doc string of `subr-arity' just send users to the doc of
`func-arity'.

In that case, the only concern is breaking existing code, but
that is often the case when deprecating something.  Just
deprecate it - no problem.

> > If my argument is being rejected (in effect - in the new doc
> > string) then why are we not doing that openly (deprecating
> > `subr-arity' and replacing it with `func-arity')?
> 
> Because you objected, and I'd rather not start yet another
> endless discussion.

No, I did _not_ object to deprecating it.  I only pointed out
that you were wrong in saying that by aliasing you would be
providing backward compatibility.  This is what I said:

  Ignoring all the rest...

(NB that part. I pointed to a problem with _one_ thing you said.)

  This sounds wrong to me.  Just calling the new code (which I
  have not looked at, but which I presume does for arbitrary
  functions what `subr-arity' does for primitives) would NOT
  provide backward compatibility, precisely because it would
  (presumably) NOT have the same behavior as `subr-arity' for
  non-primitives - it would not raise an error.

And that is the case.  Just aliasing to `func-arity' would NOT
provide backward compatibility.  Nothing wrong with deprecating
`subr-arity'.  What was wrong was your claim that aliasing will
provide backward compatibility.