bhandras
## Context After moving default logical-chain formatting off the old `BreakAtOpAction` logical path and onto the packed logical-chain formatter, there are still several formatter paths that are named or behaving as legacy compatibility code. This issue tracks which ones remain, which are active in the default next pipeline, and a proposed order for retiring or narrowing them. Current default plan still reports: ```text dsl_multiline_style=packed-chain-layout dsl_sigs_style=legacy dsl_sigs_native=true dsl_blank_lines_native=true dsl_expr_logical_style= dsl_expr_arithmetic_style= dsl_expr_case_clause_style= dsl_expr_selector_chain_style= stage.blank-lines=dsl stage.comments=dsl stage.compact-calls=dsl stage.expressions=dsl stage.multiline-calls=dsl stage.signatures=dsl ``` ## Active legacy or legacy-ish paths ### Comment formatting - `formatter/dsl_bundles_next.go` wires comments through `dsl.LegacyCommentRules`. - The implementation delegates to `internal/compat.FormatCommentsInSource` / `internal/compat/comment_formatter.go`. - This is still active by default. - This is probably the least realistic piece to convert into normal AST DSL rules. It owns prose wrapping, directive preservation, raw-string/comment exclusion behavior, and comment-block semantics rather than expression layout. - Recommendation: keep this as a specialized text/prose formatter for now, even if it remains wrapped as a DSL stage. ### Signatures - Default `DSLSigsStyle` is still `"legacy"`. - In default native mode this mostly means DSL signature rules using `FormatFuncSignatureNext` / `FormatInterfaceMethodNext`, not a first-pass whole-file legacy scanner. - However, `dsl.LegacyFuncSigFallbackRules(FormatFuncSigsInSource)` is still appended as a final fallback. - Recommendation: measure when the fallback fires, add targeted native DSL coverage for those cases, then remove or narrow the fallback. ### Arithmetic chains - `DSLExprArithmeticStyle` defaults to legacy behavior. - `LongExprRulesWithOptions` still uses `BreakAtOpAction` for legacy arithmetic. - There is already a conservative layout action for same-op arithmetic chains. - Recommendation: consider making same-op arithmetic layout the default with `BreakAtOpAction` retained only as fallback for unsupported/mixed cases. ### Case clauses - `DSLExprCaseClauseStyle` defaults to legacy behavior. - Legacy case formatting uses `BreakCaseClauseAction`. - A layout action already exists: `BreakCaseClauseLayoutAction`. - Recommendation: evaluate defaulting case clauses to layout, with golden/corpus verification. ### Packed multiline calls - Default multiline style is `packed-chain-layout`. - Method chains use layout, but generic call arguments still commonly use packed multiline behavior via `PackedMultiLineCallAction` and `FormatCallPackedMultiLineNextWithPrefix`. - This is not necessarily old scanner behavior, but the implementation and comments still preserve legacy packed output semantics. - Recommendation: leave packed call output as a first-class style for now; only rename/document it clearly so it is not confused with deprecated legacy scanners. ## Compatibility helpers that may be removable later These appear to be compatibility APIs or historical bundles rather than default next pipeline paths: - `LegacyMultiLineCallRules` - `LegacyMultiLineScanRules` - `LegacyCompactCallRules` - `LegacyBlankLinesRules` - `expressionRules` legacy-parity bundle, currently marked unused - `ExpressionRules` / `DefaultRules` compatibility entry points, depending on whether the package is treated as public API ## Proposed plan 1. Rename logical-chain `"legacy"` terminology internally/docs to `"packed"`, keeping `"legacy"` accepted as a compatibility alias. 2. Audit signature fallback usage with trace/corpus tests. Convert high-value fallback cases into native DSL signature rules. 3. Switch case clauses to layout by default if corpus/golden output looks good. 4. Switch arithmetic to layout for safe same-op chains, preserving `BreakAtOpAction` fallback for mixed or unsupported expressions. 5. Remove unused historical rule bundles where they are not needed for tests or public API compatibility. 6. Leave comment formatting as a specialized text/prose formatter unless a separate comment-specific DSL is designed. It does not look like a good fit for ordinary AST expression/layout DSL rules. ## Open question Should we formally treat the exported `dsl.Legacy*Rules` helpers and older `DefaultRules`/`ExpressionRules` entry points as public API, or can they be deprecated and removed as part of next-only cleanup?