octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59265] Partial assignment of outputs for some


From: Rik
Subject: [Octave-bug-tracker] [bug #59265] Partial assignment of outputs for some error conditions
Date: Wed, 14 Oct 2020 10:52:18 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36

Follow-up Comment #2, bug #59265 (project octave):

Since this is a rather weighty topic, should it be shifted to Discourse and
leave this bug report as a reminder that something needs to be done?

I don't have access to Matlab to check on MEX functions, but I suspect you're
right that no checking is possible unless it is put in to the code itself.

So one solution---which would be consistent across Octave built-in functions,
.oct files, and .mex files---would be for the function itself to always check
nargin and nargout and issue an error message.  We would want to agree on the
standard form of the error message, and probably even make it a standard
function in errwarn.cc, so that the same message is reliably produced.

Another approach would be to start tinkering with the DEF macros for function
declaration.  Presumably we could figure out a way to gracefully continue to
use people's existing code.  I.e., if they were using the old form of the
macro the interpreter would assume the equivalent of varargout and varargin
and not perform any verification.

I'd want to understand more about the last solution of changing the functions
to look like methods before going down that route.

We've identified three possible solutions.  Are there others we should look at
before we decide to really examine the merits of each?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59265>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]