Download the PHP package helloimalemur/rustify-php without Composer

rustify-php

Rust-like Option and Result types for PHP 8+.

Fully compatible with typical PHP code

You can: • store Option or Result in arrays • return them from any function • use them as method return types • wrap exceptions with them • integrate with your Rust backend patterns (structural symmetry)

Option and Result behave like normal objects but with Rust semantics.

Install

Usage

Construct Options

Functional transforms:

Construct Results

Chaining:

Eager vs lazy fallbacks (orElseValue vs orElse)

There are two ways to provide a fallback for Option and Result:

• Eager: provide another value right away using orElseValue(...).
• Lazy: provide a closure that will be called only if needed using orElse(...).

Option example:

Result example (note: the lazy version receives the error):

Using Option and Result for API validation

Using helpers (if_some, if_ok)

Match-like helpers (option_match, result_match)

Catching and logging errors with Result/Option

You can keep exceptions out of your core flow by returning Result/Option and logging at the boundary (controller/CLI/job). Here are a few idioms you can mix and match:

Log errors without changing the value using ifErr

Transform or annotate the error while logging using mapErr

Recover from an error while logging using orElse

One‑liner logging with defaults using unwrapOrElse

Catch exceptions once, convert to Result, then log via the patterns above

Optional values: log when a value is missing using the ifNone pattern

• Prefer logging at the application boundary (controllers, handlers, CLI commands) rather than deep inside pure functions. This keeps core code testable and composable.
• Use mapErr when you need to add context as the error bubbles up, orElse when you can safely recover with a fallback, and unwrapOrElse for concise defaulting with logging.

WHY!?

Null is not a value. It is an absence of information. It carries zero context about what and why something is, where it came from or what state the system is in.

Option and Result turn absence into structured flow, explicit alternate paths, recoverable and predictable outcomes. They convey intent, preserve context, and shorten debugging time.

Option represents an intentional “maybe”:

Some(value) → a value is present
None → a value is intentionally absent

Result represents the outcome of an operation:

Ok(value) → the operation succeeded
Err(error) → the operation failed, with a meaningful reason

By using Option and Result, the purpose of a function becomes explicit.

They eliminate ambiguity, prevent silent failures, and preserve information that null would throw away.

it’s practical
it reduces bugs
it simplifies reasoning
it improves interfaces
it prevents hours of debugging
it’s how you write reliable APIs

This is not “Functional Programming nonsense”, this is industry standard.

Swift has Optional<T>
Kotlin has Nullable<T> with smart handling
Rust has Option<T> and Result<T,E>
Haskell, Elm, OCaml all use Maybe/Result
TypeScript uses | undefined but companies implement Option for safety

Null introduces silent ambiguity

Null can mean any number of different things, but the language gives you no way to distinguish them. It could signal an error, missing data, invalid input, or an uninitialized value—yet all of these collapse into the same opaque null.

Example:

What does null mean??? user not found?.. DB error?.. invalid input?.. developer forgot a return statement?.. exception swallowed somewhere?..

In production debugging, you cannot tell which one happened.

null destroys signal clarity.

Null forces defensive code everywhere

code you’ve written a thousand times:

Your brain has to constantly do “Is null okay here, or is null an error?” This cognitive cost multiplies across the codebase.

Null often fails far away from where the real problem happened

Consider: Fatal error: Call to a member function foo() on null. The real problem happened in a function 3 layers earlier, but the crash happened way later when dereferencing was attempted.

Option and Result prevent this entirely because they force handling.

Null causes production bugs that are extremely hard to trace

If $invoice was null, you get a warning or TypeError. But logs don’t tell why it was null. No context survives and you lose the root cause.

Result fixes this by carrying failure information forward:

You cannot lose the root cause.

Option makes “maybe” explicit

When something is optional, the type should say so, not the comments, not the mental model, not tribal knowledge.

Example:

Which one communicates meaning?

?string → maybe string, maybe null, maybe error, figure it out yourself
Option<string> → explicitly either Some(string) or None, handle both

Result replaces exceptions and null-return error codes with structured information

Exceptions in hot paths suck. null for errors is painful. Result gives a middle ground:

$result = doThing();

This is the same reason Go developers use error returns:

explicit
linear
predictable
no hidden control flow

Result makes success and failure equally obvious

Both outcomes are visible. No ambiguity. No surprises.

Developers get better autocomplete and static analysis

PHPStan/Psalm can reason about:

But they cannot reason about null except “maybe null, maybe not.”

So with Option/Result:

fewer runtime errors
more pre-runtime catches
more confident refactoring