giles
21bb17e4a6
Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 23s
Phase 3 cont. The headline Go-distinguishing typing feature: interfaces
are satisfied *structurally and silently* — no `implements` declaration,
no nominal subtyping. Any type whose method set contains all the
interface's methods (with matching signatures) satisfies it.
Method declarations now type-check via go-check-method-decl:
* Receiver type extracted (T or *T → "T") via go-extract-recv-ty-name.
* Method signature (:ty-func PARAMS RESULTS) bound under a mangled
key "#method/RECV-NAME/METHOD-NAME" in ctx.
* Body checked with receiver + params extended into the body ctx.
go-iface-satisfies? CTX TY-NAME IFACE-TYPE walks the interface's
:method elements; for each, looks up #method/TY-NAME/METHOD-NAME and
compares (PARAMS, RESULTS) tuples. Embedded interfaces (:embed
elements) skipped in v0 — recursive interface resolution later.
Tests:
* method-decl binds under #method/Point/String
* pointer-receiver method also keys the base type
* Point with String() satisfies interface { String() string }
* empty type does NOT satisfy Stringer
* arity-mismatch method fails satisfaction
* multi-method satisfaction works
* partial method-set fails
types 72/72, total 377/377. Phase 3 sub-deliverable list is now
substantially complete; only AST-path error context remains as a UX
sharpener.
Sister-plan static-types-bidirectional diary updated with the
**constraint-satisfies? pluggable predicate** kit-API proposal —
third pluggable point after synth/check + assignable?. Go interfaces,
Haskell typeclasses, Rust traits, and TS structural subtyping all
answer "does this value-type fit this constraint-type?" with
different machinery; the kit's check uses constraint-satisfies? when
EXPECTED is itself a constraint type.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>