Functional extensions for result

Thu, 24 Sep 2026 00:00:00 +0300

Introduction

In an earlier post, I created Result<TValue, TError>, a generic, allocation-free struct. On its own, it supports only procedural programming. Call something, check Success or Failure, branch and repeat. This is the same boilerplate as Go’s if err != nil.

In functional languages, a result is a value like any other, so operations can be composed on it directly. F# includes a Result module for this. This post discusses extension methods that reimplement map, mapError, bind, iter, iterError, defaultValue and defaultWith for Result<TValue, TError>. They let you chain steps without checking Success or Failure after each call.

Result Pattern in C#

Tue, 15 Sep 2026 00:00:00 +0300

Introduction

Whenever I was writing C# and an edge case popped up that strayed from the happy path, I just threw an exception. At first it felt fine and natural. But later it started bothering me, every new edge case meant adding another exception type to the error handling middleware. It was especially unpleasant when trying to compose different methods in order to reuse functionality. Exceptions aren’t cheap — throwing one measurably costs more than returning a value. Nor should they be relied on for control flow.

Posts on CHANGE_ME_BLOG_TITLE

Functional extensions for result

Introduction

Result Pattern in C#

Introduction