GC003 — No Unhandled Result
This page documents the GC003 rule, which requires every Result<T> value to be explicitly consumed — via Match, Bind, Map, or a deliberate discard — rather than silently dropped.
Work in Progress
This page is under construction. MonadicLeaf is in active development.
What This Rule Enforces
When this page is complete, it will explain how GC003 uses Roslyn's data-flow analysis to track Result<T> values from their point of creation to their point of consumption. If a Result<T> is assigned to a variable that is never read, returned from a method that discards the return value, or simply evaluated as a statement without any chaining, GC003 raises a violation. This pattern is dangerous because failure information is silently lost — the operation ran, it may have failed, but no code ever checked the outcome.
Suggested Alternative
This section will describe the correct consumption patterns. Every Result<T> should terminate in a Match call that handles both the success and failure cases, be passed into a Bind or Map chain that propagates it further up the call stack, or be explicitly discarded with a documented reason when the caller genuinely does not care about the outcome. The page will show realistic examples from API controllers, background services, and domain logic.
Auto-Fix
GC003 is supported by ml migrate. This section will detail what the auto-fix does in practice: it typically wraps unhandled Result<T> expressions in a _ = ... discard as a conservative, safe transformation, and adds a comment prompting the developer to verify whether the discard is intentional.