check: two `Multiply` implementations on one type are unreachable (LINEAR.md item 12) #753

New issue

Open

opened 2026-11-13 12:39:37 +00:00 by orion · 0 comments

orion commented

2026-11-13 12:39:37 +00:00

Collaborator

Context

docs/design/LINEAR.md lists language gaps the package met. Item 12 (line 470) is open and has no issue: extend<Scalar> Matrix2<Scalar> with Multiply<Vector2<Scalar>, Vector2<Scalar>> next to with Multiply on the type is accepted and coherent, and then matrix.multiply(vector) reports "Expected Matrix2<Float64>, found Vector2<Float64>" while matrix * vector reports "Matrix2<Float64> does not implement Multiply". The checker accepts a declaration that no call can use.

Source

Cleanup audit 2026-11 (#742), finding F11; the report is docs/project/2026-11-cleanup-audit.md.
docs/design/LINEAR.md item 12. Related and closed: #440.

Goal

A decision that the checker enforces at the declaration: either the second implementation is selected by the argument type for the method call and the operator (overloading by a trait parameter), or the second with Multiply<...> is refused where it is written, with a message that names the other spelling (a named method such as transform).

Design record point

docs/design/LINEAR.md item 12; CONCEPT, the sections on operator traits and coherence. The recommendation of the audit is the refusal: CONCEPT has no overloading by argument type anywhere else, and one exception for operators is a second resolution rule.

Acceptance criteria

LINEAR.md item 12 states the decision and is marked closed
A checker test pins the outcome for the declaration, for matrix.multiply(vector) and for matrix * vector
No accepted declaration is left that neither call form can reach
The four gates and the fixpoint are green

Dependencies

None.

Seed

None expected (std/linear already uses the other spelling).

Size

One PR, one commit for the refusal; the overloading variant would be larger and needs a record first.

## Context `docs/design/LINEAR.md` lists language gaps the package met. Item 12 (line 470) is open and has no issue: `extend<Scalar> Matrix2<Scalar> with Multiply<Vector2<Scalar>, Vector2<Scalar>>` next to `with Multiply` on the type is accepted and coherent, and then `matrix.multiply(vector)` reports "Expected `Matrix2<Float64>`, found `Vector2<Float64>`" while `matrix * vector` reports "`Matrix2<Float64>` does not implement `Multiply`". The checker accepts a declaration that no call can use. ## Source - Cleanup audit 2026-11 (#742), finding F11; the report is `docs/project/2026-11-cleanup-audit.md`. - `docs/design/LINEAR.md` item 12. Related and closed: #440. ## Goal A decision that the checker enforces at the declaration: either the second implementation is selected by the argument type for the method call and the operator (overloading by a trait parameter), or the second `with Multiply<...>` is refused where it is written, with a message that names the other spelling (a named method such as `transform`). ## Design record point `docs/design/LINEAR.md` item 12; CONCEPT, the sections on operator traits and coherence. The recommendation of the audit is the refusal: CONCEPT has no overloading by argument type anywhere else, and one exception for operators is a second resolution rule. ## Acceptance criteria - [ ] LINEAR.md item 12 states the decision and is marked closed - [ ] A checker test pins the outcome for the declaration, for `matrix.multiply(vector)` and for `matrix * vector` - [ ] No accepted declaration is left that neither call form can reach - [ ] The four gates and the fixpoint are green ## Dependencies None. ## Seed None expected (`std/linear` already uses the other spelling). ## Size One PR, one commit for the refusal; the overloading variant would be larger and needs a record first.

orion added the

loop

label

2026-11-13 12:39:37 +00:00

orion referenced this issue

2026-11-13 12:41:38 +00:00

cleanup: 2026-11 audit plan (epic) #742

orion referenced this issue

2026-11-13 19:09:17 +00:00

docs(design): status lines say what is built and which issue tracks the rest #764