Bug in subsref overloading

Let us first show expected behaviour:

classdef GoodDemo
  properties
    st;
  end
  methods
    function obj = GoodDemo()
      obj.st = struct('x', {1,2,3});
    end
  end
end

good = GoodDemo;
disp(good.st(2).x); % --> 2
disp({good.st.x});  % --> [1]   [2]   [3]

However, when we overload subsref (just let it return the built-in output, nothing fancy) things break:

classdef BugDemo
  properties
    st;
  end
  methods
    function obj = BugDemo()
      obj.st = struct('x', {1,2,3});
    end
    function varargout = subsref(obj, s)
      [varargout{1:nargout}] = builtin('subsref', obj, s);
    end
  end
end

bug = BugDemo;
disp(bug.st(2).x); % --> 2
disp({bug.st.x});  % --> [1]

The problem seems to be that in the overloaded subsref somehow `nargout == 1`. Anything I am doing wrong here?

I found a bit of a crazy workaround, and the most problematic thing about it is it is only supported from 2015b onwards. The workaroud is to also overload the `numArgumentsFromSubscript` with -- big surprise -- its built-in value:

classdef WeirdFixDemo
  properties
    st;
  end
  methods
    function obj = WeirdFixDemo()
      obj.st = struct('x', {1,2,3});
    end
    function varargout = subsref(obj, s)
      [varargout{1:nargout}] = builtin('subsref', obj, s);
    end
    function n = numArgumentsFromSubscript(obj, s, ic)
      n = builtin('numArgumentsFromSubscript', obj, s, ic);
    end
  end
end

weird = WeirdFixDemo;
disp(weird.st(2).x); % --> 2
disp({weird.st.x});  % --> [1]   [2]   [3]

This works for Matlab 2015b+. Is there a way to get this working for earlier versions of Matlab? I tried setting `nargout` explicitly, but that has no effect at all.

[per isakson]

• I think this should be reported to the Tech Support, if only to increment a counter in their database.
• numArgumentsFromSubscript was introduced in R2015b. I vaguely recall a discussion on something similar at Answer or the newsgroup, but with numel

[Paul]

Yes, found a post from 2012 now (mentioning the bug was known for seven years already): http://uk.mathworks.com/matlabcentral/answers/57562-subsref-overload-has-fewer-outputs-than-expected-on-cell-attribute?s_tid=answers_rc1-1_p1_MLT

Seems related. `nargout` is off. Thanks for the bug confirmation.

edit I don't think reporting this is appropriate, though. As shown, from 2015b+ there is a workaround. So, in a crazy sense, this has been fixed already. I'm rather looking for a solution for earlier releases.

[per isakson]

It's been around since R14 (7.0) and fixed in R2015b(8.6) according to the database, see 555655

MATLAB calls overloaded subsref methods with 
incorrect nargout when evaluating indexing 
expressions that are not assigned to a variable

However, I wouldn't call your "big surprise" fixed.

[Paul]

Thank you for this. Your encouragement has led me to file the bug. :) (the link to the ticket appears not to be publicly accessible though...)

In any case, I am still looking for a workaround in older Matlab releases. Any thoughts?

[per isakson]

• Matlab is a high profile product and by filing issues we show our high expectations.
• "be publicly accessible" &nbsp I'm on a university site license and logged in on "My Account"; my name is on display above the search field.
• "Any thoughts?"&nbsp Unfortunately, no.

[Paul]

Sorry, I should have been clearer in that respect. I had no trouble following the link you provided. Rather, I meant that I wanted to give you the link to the bug I filed. But the URL seemed to be valid only when logged in. So I assume my bug report is "not publicly accessible" to you.

[per isakson]

A Guide to MATLAB Object-Oriented Programming by Andy H. Register includes extensive discussions on subsasgn and subsref. The book was published the year before Matlab introduced the new Class Object System. That's really unfortunate timing.

I found this sentence in a review at Amazon "- is nargout really as broken as it seems?" &nbsp

[per isakson]

"So I assume my bug report is "not publicly accessible" to you." &nbsp Your request will be processed. It will not be automatically included in the "bug-database". I believe that most issues are included, but that only an appropriate selection are on public display.

[Walter Roberson]

A more direct link to the report is https://www.mathworks.com/support/bugreports/555655

Answer 1

[David Foti]

Here is a little more explanation and possibly something that might help with the earlier MATLAB releases. The numel function was originally introduced before 2000 as a means of telling MATLAB how many elements to expect or request from an overloaded subsref using dot and a field or property name. It was given a default implementation that returned the number of elements in the array being subscripted. This worked for object arrays that wanted to return one array for each element in the object array. If the class wanted to emulate a numeric array using a scalar object but have fields that applied to the whole array, it could overload numel to return 1. This solution didn't always work well for more complicated forms of indexing or for what some people wanted to do with brace or cell indexing. That led to the new design that provides more information and allows the class to handle more kinds of indexing correctly.

Another motivation for the new function was the fact that numel was such a nice simple name for getting the number of elements in an array that it started getting used as a better alternative to prod(size(X)) as a way to get the total number of elements in arrays. However, classes that needed to overload numel to return 1 for subref didn't return the right value for the total number of array elements.

I don't know what your actual class needs in terms of subscripting (I assume the example is heavily simplified), but if you want something similar to what you have in your example and can live with numel not returning the true number of elements in your array, then you could overload numel to return the number of elements in st rather than the number of elements in obj. It would look something like:

classdef NumelFixDemo
  properties
    st;
  end
  methods
    function obj = NumelFixDemo()
      obj.st = struct('x', {1,2,3});
    end
    function varargout = subsref(obj, s)
      [varargout{1:nargout}] = builtin('subsref', obj, s);
    end

      function n = numel(obj)
        n = numel(obj.st);
      end
    end
  end

[Paul]

It feels a bit strange to use this workaround because I overloaded `size` to return the size of another attribute than for which I am now overloading `numel`, but based on a few tests I think this could more or less work. At least the gained functionality certainly justifies the hack. Thanks very much for the explanation too.

Answer 2

[Philip Borghesani]

I don't think there is anything new here or any new bugs here. There was a design flaw with how numel was used to implement the number of outputs from subsref in a comma separated list context, that was fixed by adding the function numArgumentsFromSubscript in R2015b. There is no way to get your desired output in previous versions of MATLAB.

To maintain compatibility with existing classes that implemented subsref, numArgumentsFromSubscript is only used when it is implemented by a class if the class implements subsref. The builtin returns the number of outputs that would be expected from the indexing operation passed as inputs provided there was no subsref function.

[Paul]

OK. So the element of surprise was designed.

Wouldn't be the first (e.g. https://uk.mathworks.com/matlabcentral/answers/306829).