GC004 — No Bool Return for Failable Operations
This page documents the GC004 rule, which prohibits returning bool from operations that can fail with meaningful context, and encourages the use of Result<T> instead.
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 GC004 identifies methods that return bool to indicate success or failure, but discard all information about why an operation failed. This is a common pattern in pre-functional codebases — for example, bool TrySave(Entity e) returns false when something goes wrong, but the caller has no way to know whether the failure was a validation error, a database constraint violation, or a network timeout. GC004 detects these methods based on their signature, naming patterns, and the absence of out parameters that might carry error details.
Suggested Alternative
This section will walk through how to replace bool-returning failable methods with Result<T> or Result<Unit>. Returning Result allows the method to encode not just whether it succeeded, but also a structured error value describing what went wrong. Callers can then pattern-match on the result to display appropriate messages, log specific error codes, or apply different retry strategies depending on the failure type.
Configuration
Because not every bool-returning method is a failable operation — some genuinely return a binary answer — this section will explain how to configure GC004 to reduce false positives. Options will include specifying naming conventions to include or exclude, suppression attributes for individual methods, and a severity override to treat GC004 as a warning rather than an error in codebases undergoing gradual migration.