deprecation: a deprecated parameter or label #46
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
A parameter cannot carry the
deprecatedclause; a renamed label is a new overload today.Source
Acceptance criteria
torb lint --fix --rule deprecatedmoves itDependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). DEPRECATION.md section 6 names the gap; the form of a deprecated parameter or label is new language surface, so refine will likely need an owner decision (design first, then checker and lint fix). No collision with CONCEPT "Open Questions" found at intake. next: refine (ready buffer is 6, so not before it drops below 2).
[loop:torbscript] refine: still queued behind the intake order. next: waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261022 until 2026-10-23T01:30:00Z
[loop:torbscript] decided by the loop: design of a deprecated parameter or label. No owner question: it is an internal language-surface choice that DEPRECATION.md section 3 already fixes the pattern for (clause with reason,
replacement:,since:), and CONCEPT "Functions" says there is no overloading by parameter type, so one signature per name.deprecated(...)clause, placed in front of the parameter inside the parameter list:fn connect(host: String, deprecated("it is called timeout now", replacement: "timeout", since: "0.4") wait: Int = 30, timeout: Int = 30). Reason first,replacement:andsince:string literals, exactly as in section 3. The formatter puts the clause on its own line above the parameter and then breaks the list one parameter per line (rule 5 stays true in spirit). A parameter is the "label" here: its name is the label at the call, so one clause covers both words.replacement:names another parameter of the same function with the same type; an unknown name or a type mismatch is an error at the clause, as in rule 2. (3) Passing both the deprecated parameter and its replacement in one call is an error (the call would say the same thing twice). (4) Variadic,var,lazyand receiver-closure parameters cannot be deprecated in this step (their meaning comes from the parameter, a relabel cannot stand in).connect(wait:)is deprecated since 0.4: " with the note naming the replacement. Same exceptions as section 3 (the declaring file, a deprecated declaration, no pattern).--deny deprecatedcovers it for free.torb lint --fix --rule deprecatedrewrites the labelwait:totimeout:where the argument is labeled. No fix for a positional use (moving it would reorder arguments) and none when the replacement is already passed.torb docJSON/page entry and the language server tag for parameters: DEPRECATION.md section 5 gets a sentence that they follow, no code here. A deprecated label of a tuple or a case field is not covered (a tuple label is documentation only, CONCEPT).[loop:torbscript] refine: ready. Goal: a parameter can carry the
deprecated(...)clause; the checker warns at a use andtorb lint --fix --rule deprecatedrenames the label to the replacement (design decided in the comment above).Implements: DEPRECATION.md section 6, "A deprecated parameter or label" (to be moved into section 3/5 by this PR).
Acceptance criteria (testable, as checker/lint/parser tests)
replacement:is another parameter of the same type, both passed is an error, excluded parameter kinds), section 5 states the lint fix and thattorb doc/torb lspfollow; the open entry in section 6 is replaced by what stays open.deprecated("why", replacement: "p", since: "0.4") name: T = din a parameter list parses; the formatter prints the clause above the parameter;torb format --checkis stable on the result. A parameter nameddeprecatedstill parses.replacement:, both parameters passed in one call, clause on a variadic/var/lazyparameter.3 files, no problems, N warningscount;torb check --deny deprecatedturns it into a problem.torb lint --fix --rule deprecatedrewriteswait: 5totimeout: 5; no fix for a positional use or when the replacement is already passed; the finding stays.a(andbwhere CLAUDE.md asks) green in forge CI.Seed touch: no. It is a syntax addition (parser, formatter), but the compiler's own source does not use the new form, so there is no migration commit and no seed refresh (the two-commit rule applies only when the compiler source adopts it).
Size: one PR, two Conventional Commits: (1)
feat(checker): deprecated parameter(design record, parser, formatter, checker rules and warning, tests); (2)feat(lint): rename the label of a deprecated parameter(fix, tests, regeneratedskills/if docs change). No split, no new issue (andgate.onis false, nothing needed).Tokens (RE worker, approx.): ~45k.
next: implement
[loop:torbscript] claim implement by session:loop-torbscript-20261023 until 2026-10-23T04:17:00Z
[loop:torbscript] implement: PR #399 is open with two commits (
feat(checker): deprecated parameter,feat(lint): rename the label of a deprecated parameter), CI green on624f143f(gates, bootstrap linux-x64, tier A, commit messages). Built as decided: clause on its own line in front of the parameter, the four rules, warning by label or position with the replacement note,--deny deprecated, lint fix renames the label.torb docand the language-server tag for parameters are recorded as following (DEPRECATION.md sections 5 and 6). Local checks: deprecation tests 45/45, format tests 76/76,docs check --no-snippetsanddocs skill --checkclean (the docs snippets run in CI). Seed touch: no. Tokens: not metered inside this subagent run, so none reported. next: review