ダック・タイピング
これはOCamlの型推論システムによってコンパイル時にすべて決定される(コンパイラによる静的な型検査を受ける)。TypeScriptの型互換性も構造的サブタイピングに基づいている。対義語は名前的サブタイピング (nominal subtyping) であり、例えばJavaやC#などの継承ベースの型システムで用いられている方式のことである。
PythonやRubyは一般的なクラス継承の機能も持っており、継承によるポリモーフィズムも利用できるが、ダック・タイピングによるポリモーフィズムは継承が不要であり、型による制約に縛られることなく簡素なコードで実現できる点にメリットがある。しかし、制約がないということは乱用しやすいということの裏返しでもある。型制約がない場合はコンパイラによる静的な型検査や統合開発環境 (IDE) によるコード補完などの支援が見込めず、プログラムの記述ミスを発見するのが難しくなることもある。Pythonのダック・タイピングでは、オブジェクトが特定の属性を実際に持っているかどうかをhasattr()で事前チェックしたり、例外処理を記述したりする方法が採られる。Pythonはダック・タイピングを補完するために抽象基底クラスの機能を導入した。
構造的型付けは名前的型付け (nominal typing / nominative typing) と対比される型システムの分類のひとつである。
この用語の名前は「ダック・テスト」に由来する。
"If it walks like a duck and quacks like a duck, it must be a duck"
(もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない)
デーブ・トーマスはRubyコミュニティで初めてこの言葉を使ったと考えられている。
C++のテンプレートはダック・タイピングの静的版である。例えば、STLにおける各種のiteratorはIterator基底クラスのようなものからメソッドを継承しているわけではないが、特定の演算子を利用できて同じ構文でコンパイルが通るならば、それはiteratorの一種として扱える。この文脈で言う「同じインタフェースを持つ」とは、コンパイラにとってシグネチャなどのインタフェースが同じだということである。したがって、iteratorの実装はオブジェクトである必要すらない。
もう1つ、ダック・タイピングに似たアプローチにOCamlの構造的サブタイピング (structural subtyping) がある。メソッドのシグネチャが互換ならば、宣言上の継承関係はなくとも、オブジェクトの型は互換であるというものである。