Re: should Octave be more strict about checking number of arguments?

On 7/9/20 1:28 AM, John W. Eaton wrote:
> Bug report 58695 raised the following issue.
> 
> Currently, Octave allows function to be called with more input or output
> arguments than can possibly be used or created.  For example,
> 
>   function f (), end
> 
> may be called as
> 
>   f (1)
> 
> or
> 
>   x = f ()   ## You do get a warning here
>   [1, f, 2]  ## But not here...
> 
> I think the original intent in Octave was to allow the call warn or
> attempt to do something reasonable (if possible) when no outputs are
> created.  So I could see a reasonable argument made for allowing this
> kind of behavior but I don't know why I thought this was a good thing to
> do and it seems reasonable to have the interpreter detect these types of
> argument number mismatches automatically.
> 
> I think Matlab always throws an error if a function is called with more
> input or output arguments than can possibly be used or generated so this
> would improve compatibility somewhat.
> 
> Should we change Octave's behavior to match Matlab?  Always?  Just when
> using --traditional mode?
> 
> jwe
> 


Previously, I tried to fix bug #58686, where a scenario showed up, that
should always make Octave follow the Matlab approach in this regard.

The short outline is, assert() can be called in two ways

   assert (expr)
   assert (val, expected)

Now I made a test like this with your example

   assert (f(1), 42)

Because f() returns nothing the call was (without warning or error)
interpreted as

   assert (42)  ==  assert (true)

and passed Octave's test suite en perfect, even my function did not work
at all.

Thus with silent argument ignoring it is easily possible to create super
trivial mistakes, which are a nightmare to detect and to debug as the
code grows and Octave's test suite is of no help then.

I vote to always follow the behavior of Matlab in this case or at least
to throw a warning.

Kai