[Octave-bug-tracker] [bug #63841] nargout is always 0 or 1 for subsref() in classdef methods

[Fernando]

Follow-up Comment #14, bug #63841 (project octave):

I'm afraid I am partly to blame for this issue, because I proposed the fix for
bug #48693.

A.R. Burgers, I could reproduce the error from your comment #11 even without
applying the patch from comment #10. There seems to be two problems here:

1. In a (multi-)assigment expression, nargout should take its value from the
number of variables being assigned. E.g. in a sentence like

[a,b]=tst_nargout.call_a_method

the value of nargout that subsref receives should be 2, no matter what the
indexing expression is. That's the problem causing this issue.

2. Octave analyzes the object indexing expression to try to set up a proper
value for nargout (this is necessary if the indexing result is not being
assigned to variables). However, this analysis is sometimes incorrect, as in
the expression

cm('first').a_property 

from comment #11. In this case, the subsref method of the containers.Map
object cm is receiving nargout=5, instead of 1, because 'first' is an array of
length 5, so octave treats this like the expression x(1:5).a_property, which
should provide 5 results.



    _______________________________________________________

Reply to this item at:

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

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