Review Result changes from Angus and industry direction

[MarkDerman]

https://github.com/MarkDerman/OrdinaryInfrastructure/pull/141/changes#diff-4d4d9acfbb455537d960d685580e2730fcd38fcdad0a3cf804205100ec05362c

[MarkDerman]

The .NET community has largely moved away from throwing exceptions for expected business logic failures (the "Result Pattern"). While .NET 10 (released late 2025) and C# 14 did not introduce a single "official" Result<T> type into the Base Class Library (BCL) for general use, the ecosystem is dominated by a few high-quality libraries and framework-specific patterns.

Here are the most popular implementations as of 2026:

1. FluentResults (The Veteran)

This remains one of the most widely used libraries. It is highly object-oriented and allows you to return multiple "Success" or "Error" objects in a single result, which is useful for complex validation scenarios.

• Key Feature: Supports "Reasons" (warnings/metadata) alongside errors.
• Nuget: FluentResults

2. ErrorOr (The Modern Favorite)

ErrorOr has gained significant traction due to its simplicity and performance. It is essentially a discriminated union of an error list or a value.

• Key Feature: Extremely clean syntax using the .Match() or .Switch() methods, and very high performance.
• Modern C#: Works beautifully with C# switch expressions.

public ErrorOr<User> GetUser(Guid id) 
{
    if (id == Guid.Empty) return Error.Validation("User.InvalidId", "ID cannot be empty.");
    return new User(id, "John Doe");
}

// Usage
var result = GetUser(someId);
var message = result.Match(
    user => $"Hello, {user.Name}",
    errors => $"Errors: {string.Join(", ", errors.Select(e => e.Description))}"
);

3. CSharpFunctionalExtensions (The "Railway" Choice)

This is the go-to for developers who want a "Functional Programming" (Railway Oriented Programming) feel in C#. It is more than just a Result class; it’s a full toolkit for handling logic as a chain of operations.

• Key Feature: Strong support for .Bind(), .Map(), and .Ensure().
• Nuget: CSharpFunctionalExtensions

4. Ardalis.Result (The Clean Architecture Choice)

Created by Steve "Ardalis" Smith, this implementation is specifically designed to bridge the gap between business logic and UI/Web APIs.

• Key Feature: Includes "Result Status" (e.g., NotFound, Unauthorized, Invalid) that maps directly to HTTP status codes.
• Nuget: Ardalis.Result

---

The State of ".NET 10" and Native Support

While there is still no System.Result<T>, .NET 10 (C# 14) and recent versions have introduced features that make the Result pattern better:

• TypedResults (ASP.NET Core): In Minimal APIs, Microsoft provides TypedResults. This is the "official" way to handle operation results in the web layer. It provides a strongly typed way to return Ok, NotFound, or BadRequest, which is excellent for OpenAPI (Swagger) documentation.
• C# 14 Extension Members: One of the biggest features in .NET 10/C# 14 is the ability to add extension properties and static extension members. This allows you to take any Result library and add your own properties (like .IsNotFound) as if they were built into the library.
• Implicit Conversions: Modern libraries take full advantage of C# implicit operators, allowing you to return user; or return Error; directly from a method that returns a Result<User>, removing the need for Result.Success(user).

Summary: Which one should you use?

• For Web APIs: Use Ardalis.Result or ErrorOr for easy mapping to HTTP codes.
• For Functional/Railway logic: Use CSharpFunctionalExtensions.
• For complex validation/logging: Use FluentResults.
• For high performance & simplicity: Use ErrorOr.