Qiskit / qiskit-fermions / 34364759259

98%

push

github

Refactor operator `groups` assignment in core (#337)

* refactor(operators): funnel every `groups` write through the trait

`OperatorTrait::set_groups` was documented as "the only route through which group indices enter an
operator", the argument being that validating there makes a corrupt operator unreachable. That claim
was false: `groups` is a `pub` field, and direct assignments bypassed the length check throughout.

Rather than route the clear-only sites through `set_groups(None)`, invert the dependency: a new
required `_write_groups` becomes the single field write, and both public setters are lifted onto it as
provided methods. Two things fall out. The length check, previously copy-pasted byte-identically into
all four operator types, is now written once. And `clear_groups` can be infallible, so the twelve
in-place operations that drop a grouping need neither an `expect` nor a discarded `Result` for an
outcome that cannot occur -- which is also what lets the C API's `del_groups` and `add_term` keep
their `void` signatures in the following commit.

The `.expect()` calls added at the remaining sites are assertions, not error handling: each one sits
next to a loop that pushes exactly one group index per appended term. `GroupingError` has no
`From<CoherenceError>` and `retain_terms` returns `()`, so propagating was not available anyway.

Two categories deliberately keep writing the field, and the trait doc is softened to say so. The
incremental builders in `library` seed an empty array on a term-less operator and then grow terms and
group indices together, so a whole-array check can only ever hold in that initial instant; a narrow
`push_group` helper was rejected because its weaker `groups.len() <= coeffs.len()` invariant would
legitimize the transient state rather than remove it. And the field itself stays `pub`: privatizing
one of five equally corruptible fields buys nothing, since pushing a coefficient breaks the pair
regardless. No lint can expre... (continued)

100 of 100 new or added lines in 13 files covered. (100.0%)

11515 of 11696 relevant lines covered (98.45%)

563571.04 hits per line