Comma-separated assignment to a table variable

The code below tests assignment by comma-separated expansion to a cell array in 3 different scenarios. In the specific case when the cell array X is the variable of a table, it fails. Why is that?

X=cell(1,3);
S.X=X;
T=table(X);

[X{:}]=deal(1,2,3)  %Case (1) : works fine

X = 1×3 cell array
    {[1]}    {[2]}    {[3]}

[S.X{:}]=deal(1,2,3)  %Case (2) : works fine

S = struct with fields:
    X: {[1]  [2]  [3]}

[T.X{:}]=deal(1,2,3)  %Case (3) : fails

Error using deal (line 37)
The number of outputs should match the number of inputs.

[Stephen23]

Table overloads both subsref and subsasgn. Its indexing is nothing like any other class.

[Paul]

Why does the second call to deal result in three copies of the same displayed output?

X = cell(1,3);
T = table(X);
[X{:}] = deal(1,2,3)

X = 1×3 cell array
    {[1]}    {[2]}    {[3]}

[T.X{1},T.X{2},T.X{3}] = deal(1,2,3)

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

[Matt J]

Table overloads both subsref and subsasgn.

Does that explain why comma-separated assignment would not be supported?

[Matt J]

Why does the second call to deal result in three copies of the same displayed output?

@Paul It is normal for unsuppressed output of CSL assignment to make nargout displays if it thinks the outputs are separate and unrelated variables, e.g.,

[a,b]=deal(1,2)

a = 1

b = 2

When you assign to separately indexed regions of the same variable, it apparently cannot tell they are related,

[X{1},X{2}] = deal(4,5)

X = 1×2 cell array
    {[4]}    {[5]}

X = 1×2 cell array
    {[4]}    {[5]}

as distinct from,

[X{1:2}]=deal(6,7)

X = 1×2 cell array
    {[6]}    {[7]}

[Stephen23]

"Does that explain why comma-separated assignment would not be supported?"

No, it explains why comparisons to other data types are not particularly useful.

[Matt J]

No, it explains why comparisons to other data types are not particualrly useful.

I don't know about that. This is a built-in Matlab data type meant as a general kind of container. All other containers support the full range of indexing.

[dpb]

" All other containers support the full range of indexing."

"All"?

map, timeseries, dataset, ...???

[Matt J]

All containers within the set of Fundamental Classes. Regardless, the main thing was that there doesn't seem to be a good reason for tables not to allow this.

[dpb]

I note there that the table/timetable are notably missing the "Use in comma separated lists" line item in the "Intended Use" column....guess it also shows how long it's been since I did more than look up individual functions in the doc -- I had forgotten about that overview page existing.

While I'd never attempted the addressing to a table in that fashion and wouldn't have thought of doing so in all likelihood anyway, I'll confess I don't know enough about the internals for it to be apparent to me why it couldn't be done; I would presume adding the additional complexity on top of existing logic could be a performance issue in adding yet another layer of complexity.

[Paul]

AFAICT, numArgumentsFromSubscript alway returns 1 for a table for assignment, at least for the various cases that I tried, which is why deal fails for the example at hand. But that also means that deal works for assigning to a scalar cell in the table variable

X = cell(1,1);
T = table(X);
[T.X{:}] = deal(pi)

T = table
        X     
    __________

    {[3.1416]}

or to one element of vector cell

X = cell(1,3);
T = table(X)

T = table
                         X                      
    ____________________________________________

    {0×0 double}    {0×0 double}    {0×0 double}

[T.X{2}] = deal(pi)

T = table
                        X                     
    __________________________________________

    {0×0 double}    {[3.1416]}    {0×0 double}

And deal can expand the table variable

[T.X{4}] = deal(8)

T = table
                             X                         
    ___________________________________________________

    {0×0 double}    {[3.1416]}    {0×0 double}    {[8]}

[T.X{2,3}] = deal(100)

T = 2×1 table
                                 X                              
    ____________________________________________________________

    {0×0 double}    {[  3.1416]}    {0×0 double}    {[       8]}
    {0×0 double}    {0×0 double}    {[     100]}    {0×0 double}

Answer 1

[Matt J]

According to Tech support, it is not a bug, just something that wasn't implemented for tables. However, they see it as a legitimate enhancement, and have filed it as an enhancement request.

Answer 2

[dpb]

As @Stephen23 notes, table addressing is its own animal...

The table is a one-row cell array in one vairable so it can be assigned directly as a cell can be...

X=cell(1,3);
T=table(X)

T = table
                         X                      
    ____________________________________________

    {0×0 double}    {0×0 double}    {0×0 double}

T.X={1 2 3}

T = table
               X           
    _______________________

    {[1]}    {[2]}    {[3]}

No need for deal() here as the dot-X notation returns the cell array in its entirety. Of course, in a table cell, it can contain anything any other cell can

T.X(1:2)={1 2};
T.X(3)={'Fred Flintstone'}

T = table
                      X                  
    _____________________________________

    {[1]}    {[2]}    {'Fred Flintstone'}

T.X

ans = 1×3 cell array
    {[1]}    {[2]}    {'Fred Flintstone'}