Skip to content

feat(dummies): add ContainingKey to the dictionary generator#286

Merged
Reefact merged 2 commits into
mainfrom
claude/issue-225-containing-key
Jul 22, 2026
Merged

feat(dummies): add ContainingKey to the dictionary generator#286
Reefact merged 2 commits into
mainfrom
claude/issue-225-containing-key

Conversation

@Reefact

@Reefact Reefact commented Jul 22, 2026

Copy link
Copy Markdown
Owner

Summary

AnyDictionary was the only collection generator without a containment constraint. This adds ContainingKey(TKey) so a test can pin that a generated dictionary holds a particular key, and — because dictionary keys already run through the same CollectionState as AnySet — it inherits the out-of-domain cardinality crediting for free, closing a coverage hole the suite explicitly comments on.

This is change 2 of the two independent changes described in #225 (the containment surface); the shared count facade is #285.

Type of change

  • Bug fix
  • New feature
  • Breaking change
  • Refactoring
  • Analyzer / diagnostic change
  • Tests
  • Documentation
  • Build / CI / tooling

Changes

  • Add AnyDictionary<TKey, TValue>.ContainingKey(TKey key): it routes to the key state's CollectionState.WithContaining, so a required key takes one entry's room and a key outside the key generator's domain extends the effective cardinality exactly as SetOf(...).Containing(...) does — the crediting already lives in CollectionState, inherited unchanged. The entry's value is generated like any other.
  • Named ContainingKey rather than a bare Containing so the surface reads unambiguously on a dictionary, whose elements are key/value pairs.
  • Declare the new member in both per-TFM PublicAPI.Unshipped.txt baselines (netstandard2.0 and net8.0).
  • Add tests exercising ContainingKey inside and outside the key generator's domain (the out-of-domain case is the path that was previously untestable through AnyDictionary), and refresh the stale comment in ContainingOutsideDomainExtendsCardinality that noted the gap.

Testing

  • dotnet build FirstClassErrors.sln — Build succeeded, 0 Warning(s), 0 Error(s) (both the netstandard2.0 and net8.0 legs of Dummies; the PublicAPI analyzer is clean).
  • dotnet test FirstClassErrors.sln — full suite not run locally; ran dotnet test Dummies.UnitTests instead: 450 passed (2 new), 0 failed, 0 skipped.
  • Analyzer tests pass (FirstClassErrors.Analyzers.UnitTests) — not run; no analyzer change in this PR.

Documentation

  • Public API / error documentation updated — the new member is declared in the per-TFM PublicAPI.*.txt baselines.
  • README / doc/ updated
  • French translation (doc/handwritten/for-users/README.fr.md) updated if user-facing behavior changed
  • No documentation change required

Architecture decisions

  • No architectural decision in this pull request — an additive method that reuses the existing collection-containment / cardinality-credit machinery (ADR-0013) unchanged.
  • New decision recorded — ADR drafted as Proposed: ADR-____
  • Supersedes an existing ADR — successor proposed, status not flipped: ADR-____
  • ⚠️ Conflicts with an existing ADR — flagged for the maintainer: ADR-____

Related issues

Refs #225 — completes the issue together with #285. Left as Refs rather than Closes so #225 is not auto-closed before both PRs merge.


Generated by Claude Code

claude and others added 2 commits July 22, 2026 09:48
AnyDictionary was the only collection generator without a containment
constraint: a test could not pin that a generated dictionary holds a
particular key, and the out-of-domain cardinality-credit path for
dictionary keys was unreachable through the public surface (the suite
comments on the gap in ContainingOutsideDomainExtendsCardinality).

Add ContainingKey(TKey): it routes to the key state's WithContaining, so
the required key takes one entry's room and a key outside the key
generator's domain extends the effective cardinality exactly as
SetOf(...).Containing(...) does — that crediting already lives in
CollectionState and is inherited for free. The entry's value is generated
like any other. Named ContainingKey rather than a bare Containing so the
surface reads unambiguously on a dictionary of key/value pairs.

Declare it in the per-TFM PublicAPI baselines, cover it with tests inside
and outside the key domain, and refresh the stale comment that noted the
gap.

Refs: #225

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018RduXUaM3V6tk6MuKxzVzJ
@Reefact
Reefact merged commit 53e27a1 into main Jul 22, 2026
16 checks passed
@Reefact
Reefact deleted the claude/issue-225-containing-key branch July 22, 2026 13:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants