Does this function appear to be row-major?

I am currently using a matrix library which defines basic operations like this:

Code :

struct Matrix4{
vec4 x;
vec4 y;
vec4 z;
vec4 w;
..... functions
}

A vec4 is simply a struct with its data as:

(T is typically a float)

The key question is probably answered by this:

Code :

Matrix4 operator * (const Matrix4& b) const
{
Matrix4 m;
m.x.x = x.x * b.x.x + x.y * b.y.x + x.z * b.z.x + x.w * b.w.x;
m.x.y = x.x * b.x.y + x.y * b.y.y + x.z * b.z.y + x.w * b.w.y;
m.x.z = x.x * b.x.z + x.y * b.y.z + x.z * b.z.z + x.w * b.w.z;
m.x.w = x.x * b.x.w + x.y * b.y.w + x.z * b.z.w + x.w * b.w.w;
m.y.x = y.x * b.x.x + y.y * b.y.x + y.z * b.z.x + y.w * b.w.x;
m.y.y = y.x * b.x.y + y.y * b.y.y + y.z * b.z.y + y.w * b.w.y;
m.y.z = y.x * b.x.z + y.y * b.y.z + y.z * b.z.z + y.w * b.w.z;
m.y.w = y.x * b.x.w + y.y * b.y.w + y.z * b.z.w + y.w * b.w.w;
m.z.x = z.x * b.x.x + z.y * b.y.x + z.z * b.z.x + z.w * b.w.x;
m.z.y = z.x * b.x.y + z.y * b.y.y + z.z * b.z.y + z.w * b.w.y;
m.z.z = z.x * b.x.z + z.y * b.y.z + z.z * b.z.z + z.w * b.w.z;
m.z.w = z.x * b.x.w + z.y * b.y.w + z.z * b.z.w + z.w * b.w.w;
m.w.x = w.x * b.x.x + w.y * b.y.x + w.z * b.z.x + w.w * b.w.x;
m.w.y = w.x * b.x.y + w.y * b.y.y + w.z * b.z.y + w.w * b.w.y;
m.w.z = w.x * b.x.z + w.y * b.y.z + w.z * b.z.z + w.w * b.w.z;
m.w.w = w.x * b.x.w + w.y * b.y.w + w.z * b.z.w + w.w * b.w.w;
return m;
}

In a column-major system, the operator* should assume that the top row of the matrix on the left is not in contiguous memory, since it stores the first element of each column vector. This function is clearly treating the first row of the left-hand matrix (the *this matrix) as contiguous, thus implying this is a row-major matrix library, right?

After looking at this stuff for so long, I gather that the only way to really determine if a library is column-major or row-major is to look how it handles multiplication with respect to how it lays out its data.

While not likely necessary to diagnose my question, the translation matrix the library provides for a 3d translation transformation places the x, y, z data in the final vec4. But this data could be in this location in either a column-major or row-major system so it's likely a trivial piece of evidence.