Just to ensure we are talking about the same things I am using these as definitions: * https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedi

Just to ensure we are talking about the same things I am using these as definitions: * https://en.wikipedia.org/wiki/Structural_type_system https://en.wikipedia.org/wiki/Structural_type_system * https://en.wikipedia.org/wiki/Duck_typing https://en.wikipedia.org/wiki/Duck_typing These are non=competing qualities. In duck typing there is no actual code interpretation, as in run time evaluation. Instead instances are compared against a type definition looking for conformance and presumed good so long as the compiler does not see a misalignment to the type definition. This is generally good enough when both the type definitions and the code instances are static qualities in the code, but exceptions can occur if there are dynamic mutations the compiler does not recognize such as extending extending a base type with a dynamic quality. Structural typing uses structures to define relationships and those relationships become points of evaluation to determine subsets. Relational evaluation is most useful in tree models such as DOM (HTML, XML), file system, certain database models like DB2, some machine learning models. The useful qualities of relationship evaluation are that you can evaluate correctness via a path, as in navigation from one node to another, and determine if a code instance is properly composed. There is some overlap between those two type definitions in TypeScript in that an object interface can be defined from various smaller interfaces. This is mostly done for code reuse, but benefits composition.