[timfennis]

A parameter annotated Iterable<T> took any kind of sequence of Ts, but an unannotated parameter already takes any sequence its body can iterate, and only the feature's own tests used it. Supporting it split each function's type in two (its declared type and the "shape" calls saw), with a separate iteration constraint per such parameter. A review of the type checker flagged it as costing far more code than it gave users.

Iterable<T> can no longer be written in a type annotation, for a parameter as for a value: "Iterable<T> can't be written in a type annotation", with help to leave the parameter unannotated or name the kind of sequence. Built-in signatures keep it.

This deletes the shape table and callable_type (every caller now reads the declared type), the parameter-annotation lowering that split off the element type, and the per-parameter iteration constraints and runtime types for such parameters. The Iterable tests that only covered the annotation go; the others now use unannotated parameters. The manual's section on it now describes unannotated parameters.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T16:39:04.514311Z	e546dd4	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.