decide: four uncounted boolean operands, and whether terminal sets should be token arms

[dekobon]

Status: decided and landed (747b0b3c, branch fix/issue-1461).
All four items plus the structural pass. The decision, the full
per-language classification table, the before/after measurements, the
double-count check and the corpus delta are in
this comment.

The rule now is: a relational operator scores by use, wherever it
is written; a value-bearing operand scores in a boolean slot. Nine
constructs moved or were added accordingly. One of 1,610 integration
snapshots moved.

Two premises of the body below no longer reproduce. Item 3 shipped
in b2b78598 by the wrapper peel rather than the terminal set, so
if (a as Boolean) already scored 1 before this change. Item 2's
"corpus cost is zero" is true of matches! and false of the arm:
serde's one moved snapshot is if cfg!(no_underscore_consts).

One case could not take this route. Perl's bare /re/ is
relational in role, but an unconditional arm would also fire on the
pattern inside $x =~ /re/, whose =~ is already counted — measured,
that scores the bound form 2. Tracked separately as #1467, which needs
a gated arm rather than an unconditional one.

---

Summary

Four constructs measured as scoring zero ABC conditions in a boolean slot
where an identifier control scores one — but where counting them is a
judgement call rather than a clear omission. Split out of the
uncounted-boolean-operand sweep on fix/batch-2026-09-13 deliberately, so
the decision is made explicitly rather than inherited from a bulk change.

All measured against if (a) / equivalent at the same cyclomatic.

The four

1. Python walrus — if (n := g()): scores 0, control scores 1

Python::NamedExpression (123) is absent from python_bool_terminal_kinds!.

Why it is a judgement call: NamedExpression already scores on the A
(assignment) axis (src/metrics/abc/python.rs). Counting it on C as well
makes it the only construct in the survey that scores twice across two axes.
That is defensible — the axes are independent, and if (n := g()): genuinely
is a decision on g()'s truth — but it is a policy call about ABC's axes,
not a missing arm.

2. Rust matches! — if matches!(x, Some(_)) scores 0, control scores 1

Rust::MacroInvocation (239) is absent from rust_bool_terminal_kinds!.

Why it is a judgement call: the fix would fire for every macro in a
boolean slot — cfg!, dbg!, todo! — not just matches!. And
src/metrics/abc/rust.rs deliberately excludes macros from Branches.
That is the B axis rather than C, so it does not contradict, but it is a
considered omission in the immediate neighbourhood and any fix should say why
C differs from B.

Note the terminal sets do not otherwise discriminate on return type —
CallExpression counts in a boolean slot whatever it returns, and the Kotlin
infix_expression comment added in #1421 says so explicitly. That argues
for counting it; the macro breadth argues against.

Corpus cost is zero: no serde file uses matches! in a boolean slot.

3. Kotlin as — if (a as Boolean) scores 0, control scores 1

Kotlin::AsExpression (220) is absent from kotlin_bool_terminal_kinds!.

Why it is a judgement call: a cast to Boolean is unusual code, and the
set already carries AsQMARK handling elsewhere. Low value, low risk, but
not obviously right.

4. Groovy <=> — spaceship_expression (257)

Why it is a judgement call, and a different one: <=> returns an
Integer, not a boolean. Counting it as a comparison operator is right —
every other language with a spaceship counts it — but putting it in the
terminal-bool set asserts something else: that its value is a boolean
operand. Those are different claims and the second is false.

If it is counted, the route should be a condition token arm, not the
terminal set.

The structural point underneath all four

Terminal-set membership is narrower than a token arm, and that asymmetry
is now inherited by the fixes already shipped.

A kind in <lang>_bool_terminal_kinds! scores only in a boolean slot
(if / while / do / for / ternary / &&-operand). A comparison
token scores everywhere. So on fix/batch-2026-09-13:

val b = a == c        // 1 condition  (EQEQ token, counted unconditionally)
val b = a is String   // 0 conditions (IsExpression, only reaches the slot)

and identically in C#: var b = x == 1; scores 1, var b = x is int; scores
0, because csharp.rs counts EQEQ unconditionally and has no Is token
arm.

Fitzpatrick Rule 5 scores relational operators by use, not by slot. So
the is / in fixes in #1421 and the C# is fix are arguably half-landed:
correct inside a condition, still zero outside one.

Deciding this settles all four cases above and several already shipped, so it
is probably the thing to decide first.

Related

• meta: sibling sweeps are asserted rather than measured #1458 — sibling sweeps are asserted rather than measured; this issue is
  part of repaying that.
• fix(abc/kotlin): subject-less when arm double-counts its comparison operator #1421 — added Kotlin is / in / infix to the terminal set.
• fix(abc): numeric operands score no condition in PHP, Groovy and the C family #1410 — the numeric-literal instance of the same mechanism.

[dekobon]

Item 3 (Kotlin as) shipped in #1459 — three items remain

b2b78598 on fix/batch-2026-09-13 implements item 3, but by a different
route than this issue proposed, so the issue body's premise no longer
reproduces. Recording it here rather than leaving a reader to rediscover the
discrepancy (AGENTS.md, "Re-verify a deferred issue's premises before
building on them").

What changed. if (a as Boolean) and when { a as Boolean -> … } now
score 1, not 0. This issue predicts 0.

Why the peel rather than the terminal set. Adding AsExpression to
kotlin_bool_terminal_kinds! — the fix this issue names — would have
collided with AsQMARK, which is already a condition token in the same file.
Measured: peeling or listing as? as well scores a as? Boolean 2
against every other spelling's 1, the §5 double count. So as is owned by
the wrapper peel (kotlin_wrapper_operand) and as? stays owned by its
token, and both spellings come out level at 1.

The issue's literal claim that AsExpression is absent from the macro is
therefore still true — it was never added — while the behaviour it
describes has changed. That is the part worth knowing before reproducing.

Still open and undecided: items 1 (Python walrus), 2 (Rust matches!)
and 4 (Groovy <=>), and the structural question in the closing section —
whether terminal-set membership should be a token arm, so a relational
operator scores by use rather than only inside a boolean slot.

One correction to item 2 while I am here: its "corpus cost is zero" line is
true of matches! specifically and false of the arm as a whole. Adding
Rust::MacroInvocation moves one serde snapshot, and the construct that
moves it is if cfg!(no_underscore_consts) — a cfg!, not a matches!.
That is precisely the breadth this item asks about, so the measurement is
evidence for the decision rather than a footnote to it.

[dekobon]

Decided and landed: all four items plus the structural pass (747b0b3c)

The structural change went in whole. The go/no-go checkpoint was a
corpus measurement, and the answer was not close — see "Corpus" below.

Item 3 (Kotlin as) — confirmed shipped, no code change

Verified on this branch at the current tip. if (a as Boolean) and
when { a as Boolean -> … } each score 1, via kotlin_wrapper_operand
as b2b78598 describes, and a as? Boolean scores 1 too. The issue
body's literal claim still holds — AsExpression is not in
kotlin_bool_terminal_kinds! and was never added — while the behaviour
it predicts (0) no longer reproduces.

The rule, stated

A relational operator scores by use: wherever it is written.
A value-bearing operand scores in a boolean slot: where a walker
reads it as a predicate.

<lang>_bool_terminal_kinds!() is the second of those and only ever
was. Membership is slot-scoped by construction — every walker consults
the set inside an if / while / ternary / &&-operand slot and
nowhere else — which is the right scope for a value whose truthiness is
interesting only because the slot reads it, and the wrong scope for an
operator. That mismatch is what produced val b = a == c scoring 1
beside val b = a is String scoring 0.

The line is the construct's value, not its type. A cast, a Go type
assertion, an Objective-C @available query and a Rust matches! all
yield something the slot then reads as a boolean, so they stay. A type
test yields the comparison's own result, so it moves. Groovy's <=>
moves although its value is an Integer — Rule 5 measures the
comparison, not what it returns.

Classification: every member of every terminal set

Twenty sets, 300-odd members. Every member not named below is a
value-bearing operand and stays slot-scoped; the table lists only
the ones that are not, plus the judgement calls worth recording.

Language	Member	Verdict
C#	IsExpression (391)	operator — moved
C#	IsPatternExpression (392)	operator — moved
Java	InstanceofExpression (151)	operator — moved
Groovy	InstanceofExpression (224)	operator — moved
Groovy	MembershipExpression (223)	operator — moved
Groovy	(new) LTEQGT (107)	operator — added as a condition token
Kotlin	IsExpression (219)	operator — moved
Kotlin	InExpression (218)	operator — moved
Ruby	TestPattern (253)	operator — moved
Python	(new) NamedExpression (123)	operand — added, stays slot-scoped
Rust	(new) MacroInvocation (239)	operand — added, stays slot-scoped
Perl	PatternMatcher (337), PatternMatcherM (336)	operator in role, stays — see below
Kotlin	InfixExpression	operand — a general function call, out of scope as stated
Go	TypeAssertionExpression	operand — x.(T) evaluates to T, not to a bool
C family	cast_expression, available_expression	operand — a cast is type-preserving; @available is a runtime query, not a comparison
Java / Groovy / C# / PHP	CastExpression, ParenthesizedTypeCast	operand
every set	the 55 literal kinds 61a28712 added	operand, as stated

Two sets contain no relational member and needed no change:

• Python already scores by use. in / is / not in / is not
  are children of ComparisonOperator, which is an unconditional arm in
  src/metrics/abc/python.rs. The issue's "Python and Elixir in /
  is / =~" line is right about the constructs and wrong about where
  they live.
• Elixir's set is all operands. Its in and =~ are
  binary_operator nodes whose operator tokens are counted by no
  arm — a separate gap from this one (neither is in a terminal set to
  move), not addressed here.

Perl is the one place the rule could not be applied, and the reason
is instructive. PatternMatcher / PatternMatcherM (the bare /re/ and
m{re} matching $_) are relational in role, but the ABC walk visits
every node, so an unconditional arm would also fire on the pattern inside
$x =~ /^#/ — whose EQTILDE is already a token arm. Measured, that
makes the bound form score 2: the §5 double count, and the same
collision that sent Kotlin's as through the wrapper peel in #1459. The
residual gap is real and measured (my $r = /^#/ scores 0 against
my $r = ($x =~ /^#/)'s 1) and needs a gated arm rather than an
unconditional one, so it is filed as #1467 rather than folded in here.

Measured, before and after

bca metrics --no-config, abc.conditions per function, release binary
rebuilt inside each measurement step.

Language	Construct	Outside a slot	Inside a slot	== control
C#	x is int	0 → 1	1 → 1	1
C#	x is null	0 → 1	1 → 1	1
Java	x instanceof String	0 → 1	1 → 1	1
Groovy	x instanceof String	0 → 1	1 → 1	1
Groovy	x in l	0 → 1	1 → 1	1
Groovy	a <=> b	0 → 1	n/a	1
Kotlin	a is String	0 → 1	1 → 1	1
Kotlin	a in 1..2	0 → 1	1 → 1	1
Ruby	a in Integer	0 → 1	1 → 1	1
Python	(n := g())	0 → 0 (operand)	0 → 1	1
Rust	matches!(x, Some(_))	0 → 0 (operand)	0 → 1	1
Rust	cfg!(unix)	0 → 0 (operand)	0 → 1	1

Controls that must not move, and did not: JavaScript, TypeScript, Tsx,
Mozjs, Lua and PHP fixtures unchanged throughout.

Double-count check (§5)

Every "inside a slot" column above is unchanged, which is the check:
the slot stopped counting the construct in the same change that gave it
an arm. Per language, plus the shapes that could collide:

Language	Shape	Before	After
C#	if (x is int && b)	2	2
C#	if ((x is int))	1	1
C#	case > 0 when x is int	2	2
C#	catch (E e) when (x is int)	3	3
Java	if (x instanceof String && b)	2	2
Groovy	for (x in l) — the shared in	0	0
Groovy	if ((a <=> b) > 0)	1	2 (two operators, correct)
Kotlin	when (x) { is String -> } subject-ful	1	1
Kotlin	when { x is String -> } subject-less	1	1
Kotlin	for (q in l) — the shared in	0	0
Kotlin	if (!(x is String))	1	1
Ruby	case a; in Integer; else	2	2
Ruby	(x in Integer) && z	2	2
Ruby	for q in l — the shared in	0	0
Perl	$x =~ /^#/ (why Perl stayed)	1	1

The for … in … rows are why all three count the node and not the
token: the keyword is shared, the production is not. Verified with
bca dump that a subject-ful Kotlin when spells its patterns
range_test / type_test, which this arm never sees, and that Ruby's
test_pattern, in_clause and for are three separate productions.

Grammar-dispatch §1 and §2: none of the nine moved or added kinds has a
numeric-suffix alias in its enum, and all nine are emitted (each was
measured scoring). §7: <lang>_bool_terminal_kinds!() is consumed only
under src/metrics/abc/, so is_string / get_op_type /
is_func_space / get_space_kind are untouched by this change.

Two gaps that closed as consequences

• C#'s x is > 5 now reads 1 wherever it sits — level with the
  x > 5 it is sugar for. fix(abc/csharp): relational pattern operator double-counts against its arm #1383 recorded that asymmetry as a deliberate
  exception to Rule 5, kept because its only route was to readmit the
  pattern's < / > token, which would have scored the decision-slot
  case twice. Counting the enclosing is test instead has neither
  problem. csharp_relational_pattern_outside_a_decision_slot_scores_zero
  is renamed to ..._scores_one_wherever_it_is_written and inverted.
• fix(csharp): a when guard on a switch arm is a branch neither metric counts #1422's guard claim ("a guard scores one however it is spelled")
  now holds through a second mechanism rather than through the terminal
  set, unchanged in value.

Corpus

Threshold stated before measuring: disproportionate = more than 25% of
any one corpus's snapshots, or more than 150 snapshots overall.

Corpus	Snapshots	Moved
DeepSpeech (C/C++)	1042	0
pdf.js (JS)	384	0
serde (Rust)	172	1
csharp	6	0
php	6	0
total	1610	1 (0.06%)

Nowhere near the threshold, so the pass landed whole.

The one file is serde_derive/src/dummy.rs, moved by
if cfg!(no_underscore_consts) — a cfg!, exactly as the previous
comment predicted, and not a matches!. Diff is metric-value-only
(conditions 3 → 4 and its derived magnitude / averages). Accepted
via cargo insta test --review, pushed to
dekobon/big-code-analysis-output main as 062ae343, and the parent
records that SHA in the same commit as the fix.

The zeros are honest but not all informative. Four of the five
structurally changed languages have no corpus at all — nothing carries a
.groovy, .kt, .rb or .java file — and the six-file C# corpus
contains no is anywhere. So the corpus confirms the C-family, JS and
Rust trees are unaffected; it says nothing about the five languages this
change is mostly about. The before/after tables above are the evidence
for those.

Tests

Seven new tests in src/metrics/abc.rs, one per language touched. Each
carries the construct outside a boolean slot (the case the change
exists for, and which no prior fixture covered), a == control member
at the same value so the outside score is a claim about the construct
rather than about the member shape, the in-slot and &&-chain paths
that must not move, and — in Kotlin, Groovy and Ruby — a for … in …
member that must stay at 0.

Verified by a scripted perturbation sweep (sources read once into
memory, restored in a finally, perturbation confirmed applied before
any result was believed, verdicts cross-checked against exit status in
both directions, --no-fail-fast). Each of the eight production edits
was neutralised in turn:

Perturbation	Tests that noticed
C# is arm	7
Java instanceof arm	2
Groovy in / instanceof arm	4
Groovy <=> token	1 — the new test, its only coverage
Kotlin is / in arm	2
Ruby test_pattern arm	3
Python NamedExpression	1
Rust MacroInvocation	1
(restored)	pass

Independently, every new fixture was measured against a pre-change
release binary: each out* member read 0 there and reads 1 now.

Docs

CHANGELOG.md carries a Metric drift entry naming all seven
languages; big-code-analysis-book/src/metrics.md gains a deviations
row stating the rule in both directions, and its < / > row is
corrected where it asserted the now-closed #1383 exception.

make pre-commit: BCA_GATE: pass. No baseline refresh was needed —
kind_sets.rs crossed the soft loc.sloc tier on comment growth and
was trimmed back under it rather than baselined.