Function prototype of built-in functions

@Rik recently pushed a changeset that removed the BISTs that check for number of input arguments of built-in functions:

Shouldn’t we continue to have these BISTs?
AFAICT, there is no way the interpreter could determine the maximum number of arguments a built-in function can handle. Or is there?
If we still need that built-in functions have a if (args.length () > max_args) or similar check at the beginning of their body, I’d argue that we should continue to have BISTs that check if these checks are there.


Yeah, I think you’re right. It is only the interpreter for m-files which added checking for the correct number of inputs and outputs. I’ll revert the changeset that applied to C++ files.

We can modify the DEFUN macros, or introduce additional tags like the “doc:” marker that we use to introduce docstrings, to provide the maximum number of inputs and outputs for built-in functions. Then we would just need to tag the built-in functions. Tedious, yes, but certainly possible.

See also this thread: that describes the mostly unused “classes:” tag that I introduced about 4 years ago so that built-in functions could dispatch on types in ways that are similar to class methods, limiting them to a particular set of argument types. Maybe we could tag built-in functions with types and max nargin/nargout values at the same time?