ROneCOne 1.8.1

ROneCOne 1.8.1

A patch release for two defects in the same family: VBA quietly dereferencing a runtime value
through its default member, or refusing to reach a Friend member at all, when a value travels as
an Object or a Variant. Both were reported with reproductions, both were confirmed live
before any code changed, and both are now guarded by source contracts so the class of defect
cannot return rather than only the reported site.

No public surface changed. Upgrading is a drop-in replacement of ROneCOne.cls.

Fixed

• OneOf given a single ROneCOne sequence raised run-time error 438 instead of building the
  membership condition (issue #3).
  IsSequenceContainer read the Friend InternalRole through an Object local, and VBA keeps
  Friend members off the IDispatch interface, so the read compiled clean and failed only when
  executed, even though the caller is the class that owns the member. Binding through a typed
  local fixes it. Every previous OneOf test passed an array or two scalars, so nothing reached
  the branch, which is how it survived.
• IsArray left a stray error behind when handed a Variant holding a runtime value
  (issue #4). IsArray evaluates its
  argument in a value context, so VBA dereferenced the object through its default member, Run,
  which rejects the zero arguments that dereference supplies. The raise was swallowed wherever a
  caller had On Error Resume Next active, which propagates into callees with no handler of their
  own, so calls returned correct answers while leaving Err dirty for the caller to trip over
  somewhere unrelated. Two further call sites were exposed to the same hazard, in
  DeserializeOnly and in primary-key argument building.

Guards added

Both fixes are enforced structurally rather than by the single repaired line. A source contract
sweeps every procedure for a Friend member read through an Object or Variant local, joining
line continuations and cross-referencing all 270 Friend members; it found exactly one occurrence,
the reported one. A second contract asserts that IsArray appears exactly once in the runtime,
inside a guarded IsArrayValue helper that tests IsObject first, since an object is never an
array.

Release evidence

Each of three fresh Microsoft 365 Excel processes passed 959 live assertions, up from 955 by four
new cases covering OneOf with a sequence, a single-match sequence, and the bare Where()
receiver that exposed the second defect. That last case asserts the error state rather than only
the answer, because a correct answer was exactly what hid the bug. All ten suite benchmark
scenarios met their release gates in every sample; the medians ran invocation 0.11, collection
0.16, ordering 0.90, SHA-256 at 10,000 and 100,000 elements 0.13 and 0.23, keyed mutation 0.63,
and constrained maintenance 0.45 seconds.

Static analysis reported zero diagnostics across the runtime source, the live test modules, and
all fifteen demo modules; 79 Python contract tests pin the source and demo shapes. Every packaged
VBA module round-tripped byte-for-byte.

Method note

Neither report was taken on faith. Each was reproduced against the current runtime in a headless
instance before a line changed, and the second was localized by tracing Err through a throwaway
instrumented copy of the class, which showed the error appearing between two adjacent statements
and identified IsArray as the value context responsible. Static analysis passes both defects
cleanly, so only a live run could have found either.

Full changelog