Implicit expansion turned my shape bug into a matrix

Julia went the other way on this, which is why I rarely hit it. [1 2 3] + [1, 2, 3] throws a DimensionMismatch there. Broadcasting happens only when you ask for it with a dot, [1 2 3] .+ [1, 2, 3], and then you get the same 3 by 3 result.

So the shape bug still exists. It needs a dot to trigger it, which is a smaller target. The place people lose track is @., which puts a dot on every call and every arithmetic step in a long expression.

The dot only removes the silent version, though. Try changing just one thing in kvl's example and write sum(a .* b) in Julia. You get a single number back, not a row, because sum without dims adds every element. A different wrong answer from the same root cause, and now I'm curious which one people catch sooner.

My own advice above needs a correction. An arguments block with a (1,:) double does not reject a column vector. MATLAB reshapes it into a row to satisfy the size, and the validation docs list that conversion on purpose. So the check I added to catch wrong orientation repairs it instead, and says nothing.

For the function, fine, it gets a row. For me it meant the caller kept building columns and nothing ever said so. The entry check is explicit now, and the arguments block only does the class.

function s = total(a)
    arguments
        a double
    end
    if ~isrow(a)
        error("total:notRow", "expected a row vector")
    end
    s = sum(a);
end

Now a column gets total:notRow at the call instead of a quiet reshape.