In TypeScript, does swapping the operands of an intersection type — writing `B & A` instead of `A & B` — ever change how the resulting type behaves?

## The property case: genuinely order-independent An intersection of two object types produces a type whose members are the union of both member sets, and where a name appears in both, the member's type is the intersection of the two contributions. Both of those operations are commutative, so for property-only types the ordering has no semantic effect: ```typescript type A = { id: string; a: number }; type B = { id: string | number; b: boolean }; type AB = A & B; // id: string & (string | number) => string type BA = B & A; // id: (string | number) & string => string declare let ab: AB; declare let ba: BA; ab = ba; // OK ba = ab; // OK ``` This is what people mean when they say intersections have no precedence: unlike a heritage clause, where the derived declaration overrides the parent's, `&` has no "winner". If two constituents disagree irreconcilably, the member becomes `never` regardless of which side you wrote first. ## The exception: call and construct signatures A type can carry call signatures, and intersecting two callable types does not intersect the signatures — it **concatenates** them into an overload set, in operand order. Overload resolution then walks that list top to bottom and commits to the first signature whose parameters accept the supplied arguments. The consequence is that the operand order decides which overload wins whenever more than one could match: ```typescript type StrFirst = ((x: string) => "s") & ((x: unknown) => "u"); type UnkFirst = ((x: unknown) => "u") & ((x: string) => "s"); declare const a: StrFirst; declare const b: UnkFirst; const r1 = a("hi"); // "s" — the string signature is tried first and matches const r2 = b("hi"); // "u" — the unknown signature comes first and also matches ``` Both types accept exactly the same arguments; they differ only in the *result* they infer. The same applies to methods declared on the two operands: intersecting `{ f(x: string): void }` with `{ f(x: number): void }` yields an `f` with two overloads rather than a `never` member, because the collision is between call signatures, not property types. This is not a curiosity. It is the mechanism behind hand-written overload ordering in declaration files, where a library intersects a specific signature with a fallback and relies on the specific one being written first. ## Where order shows up cosmetically Even in the property-only case, order leaks into the developer experience. Hover text and error messages generally print constituents in the order you wrote them, so `Props & { children: ReactNodeLike }` and the reverse produce differently-shaped diagnostics for the same underlying type. On a deeply nested alias chain that difference decides whether an error message is readable at all. ## What to do with this in practice - Do not rely on operand order to "override" a property. It does not override; it intersects, and a conflict silently produces `never`. If you want an override you want a heritage clause, not `&`. - Do rely on operand order when you are deliberately building an overload set, and write the most specific signature first, since resolution stops at the first match. - Be suspicious of a bug report of the form "the same call returns different types in two places" where both sites use an intersected callable. Check whether the two aliases were assembled in different orders. - Remember that all of this is compile-time only. The emitted JavaScript is identical whichever order you wrote; only the checker's answers change.