Semantic Completeness for Correct Maintenance: A Strict Hierarchy of Typing and Inheritance

Removing nominal types or inheritance is often defended as reducing developer burden. The cited Java and Go rationales give no objective measure. Correct maintenance minimizes required facts left for code or tooling to supply and repairs forced by changes, while preserving required facts and behavioral correctness as a program's intended behavior evolves. Semantically complete languages derive all required type identities, interface memberships, and implementation-class pairs as finite requirements evolve. Incompleteness cannot guarantee the optimum. It forces slop: code restating facts that complete languages derive natively once.

In 20 pinned multiple-inheritance Python projects, recovered pairs grouped by declaring class would need code or tooling: 12,880 without inheritance, 8,792 under first parents, 739 under one parent inheriting only required pairs (certified exact), 0 with multiple parents. With code and state in each provider, state-bearing requirements force 236 outside pairs. Java and C# interface defaults supply no instance state. Of the top 150 pure-Python downloads, at least 24 of 65 size-qualified wheels have positive recovered gap (36.9%, 34 unscored).

For independent providers, the minimum covers reparenting, infinite helpers, delegation, and generators. One parent covers all pairs exactly when providers' class sets nest or do not overlap; likewise for contracts. Look-alike records needing different handling need as many keys as the confusability graph's chromatic number. As requirements grow and stay tree-shaped, inserting a provider outside the old ancestor path strictly between ancestors forces one-parent repair. Our zero-gap construction repeats it; multiple parents add one edge per change. Bans cannot lower minima at fixed design costs; savings require otherwise choosing worse than the best.