Result<T, E> type in PHP

I think your implementation doesn't really replicate both approachs, and is a bit too raw, you have a middle ground between Rust and Go approachs, but with the bad sides of both.

Actually you can do the same as Go in PHP, because PHP has the destructuring feature (the list), and all that Go does is return a tuple:

function ok(mixed $value): array
{
    return [$value, null];
}

function err(mixed $error): array
{
    return [null, $error];
}

function divide(int $x, int $y): array
{
    if ($y === 0) {
        return err('Division by zero');
    }

    return ok($x / $y);
}

[$value, $error] = divide(10, 0);

if ($error !== null) {
    echo $error;
} else {
    echo $value;
}

I can make a similar argument for the Rust example (because PHP enums can be used on match expressions), but the PHP version is a bit verbose to declare, and actually pretty elegant on usage:

enum ResultKind
{
    case Ok;
    case Err;
}

readonly class Result
{
    const Ok = ResultKind::Ok;
    const Err = ResultKind::Err;

    public function __construct(
        public ResultKind $kind,
        public mixed $value = null,
        public mixed $error = null
    ) {
    }

    public static function succeed(mixed $value): self
    {
        return new self(ResultKind::Ok, $value);
    }

    public static function fail(mixed $error): self
    {
        return new self(ResultKind::Err, null, $error);
    }
}

function divide(int $x, int $y): Result
{
    if ($y === 0) {
        return Result::fail('Division by zero');
    }

    return Result::succeed($x / $y);
}

$result = divide(10, 0);

$message = match ($result->kind) {
    Result::Ok => $result->value,
    Result::Err => $result->error
};

echo $message;

This is just glorified status codes that were the problem all those years ago when we invented exceptions to solve the madness that was error handling on procedural languages via defensive programming, as you didn't have a way to force the programmers to handle all the possible errors, the actual error handling was tied to knowing the documentation of the possible returns of that function (much like most of the PHP functions where you need to read the docs to understand the meaning of the return values).

Exceptions will blow out the code on the spot, so this forces you to at least know that the error exist. The biggest win we gain when using Exceptions is programming only worrying about the happy path, and leaving to handle the error path on a later moment of the code.

Functional languages, and Rust by extension, have a way to use a status code-like solution and still have similar benefits to Exceptions because their compilers enforces exhaustive type check on the match blocks so you still are required to handle all the possible errors by a type-level constraint, so you retain the requirement of knowing all the possible outcomes in the code and handle them all.

If was just that, the argument would end much like the Go approach of being just a better status code, but not much an improvement over Exceptions, so people won't become crazy hyped about function error handling and shitting over exception like they are now.

The big advantage of the functional approuch is not handle the error with defensive programming that forces you to think about both happy and error paths at the same time, but in a monadic-way, so that we can apply the idea of the railway oriented programming, and just handle the happy path first, and after handle the error path, while having the ability of compose the errors (which you have to do manually in the Go approuch).

So that instead of handling the values and worrying about them being null, you can just compose the computations that should be applied on them, by using the map and mapError operations, so you never touch the internal value of the Resut directly.

PHP has some degree of support for FP, but clearly it more idiomatic code would be more OO or procedural style, so or you stick to Go style handling, or we could adapt the Rust style to implement a Result monad-like type in a OO style rather than in a FP style, by relying on, surprisingly, inheritance, and implement a object similar to how booleans should be implemented in a OO-way:

<?php
abstract class Result
{
    public function __construct(protected mixed $value)
    {
    }

    public static function ok(mixed $value): static
    {
        return new Ok($value);
    }

    public static function err(mixed $error): static
    {
        return new Err($error);
    }

    public function isOk(): bool
    {
        return false;
    }

    public function isError(): bool
    {
        return false;
    }

    public function map(callable $fn): static
    {
        return $this;
    }

    public function mapError(callable $fn): static
    {
        return $this;
    }

    abstract public function match(callable $ok, callable $err): mixed;
}

class Ok extends Result
{
    public function isOk(): bool
    {
        return true;
    }

    public function map(callable $fn): static
    {
        return new self($fn($this->value));
    }

    public function match(callable $ok, callable $err): mixed
    {
        return $ok($this->value);
    }
}

class Err extends Result
{
    public function isError(): bool
    {
        return true;
    }

    public function mapError(callable $fn): static
    {
        return new self($fn($this->value));
    }

    public function match(callable $ok, callable $err): mixed
    {
        return $err($this->value);
    }
}


function divide(int $x, int $y): Result
{
    if ($y === 0) {
        return Result::err('Division by zero');
    }

    return Result::ok($x / $y);
}


divide(1, 1)
    ->map(fn(int $x) => print "Only handle success");

divide(1, 0)
    ->mapError(fn(string $err) => print "Only handle error");

divide(1, 0)->match(
    ok: fn(int $x) => print "Handle both",
    err: fn(string $err) => print "like Rust",
);

if (divide(1, 0)->isOk()) {
    echo "supports procedural style defensive programming";
}

This solution, in my opinion, translates better the objectives we trying to get from Exceptions, Rust and Go error handling styles. Because we can actually:

• do railway oriented programming (program happy path first, and error path after);
• represent the errors without relying on contextual documentation;
• force the programmer to handle the errors on a unsafe operation (the match method that requires you to handle both cases before unwrap the value);

Sounds like you want to use Gernics, and you can alread use them in php, validated via phpstan (in the CI pipeline) and with autocompletion via e.g. Phpstorm: chatgpt.com/share/671d8224-edb8-80...

Thanks for the post, I was literally thinking about this Idea after touching golang and was interested in your exploration of this idea. Pros of this approach - explicit handling of all possible errors, this makes programmers think of it at least for a bit and something about it. Though good programmers should do it anyway. The cons - code bloat. Imagine there might be 5 or even more possible errors, and a chain of method calls - this would produce pretty long switch/match expressions in multiple places. This is not bad per se, just a tradeoff. With exceptions you could hide under the carpet all cases that you do not foresee or don't bother to care and simply handle all other cases with general catch{Throwable}. Another point is that there could be an exception thrown in your switch/match if you would try to do something more sophisticated than checking length and call some custom logic. I think php relies on exceptions heavily and passed point of no return, to me using this approach in php is something similar to using raise / recover in go. Not impossible but somewhat strange. Thanks again for the post!

Unfortunately, this pattern does not give you any type-safety in PHP - and therefore no real guarantees or safety, like you would get in Go or Rust.

You can work around that with generic type-annotations using something like PHPStan or another type-checker - but personally, I find the most explicit approach is a simply type union like Result|Error as you can see for example here:

github.com/mindplay-dk/timber/blob...

The explicit return type encourages the caller to use an instanceof type-check, which (in most IDEs and tools like PHPStan) will correctly narrow the local variable type in an if/else block.

This way, you avoid introducing a pseudo-generic abstract "result" type, which becomes a global dependency in your projects.

To really leverage this pattern, use a pair of case-dependent return types in your return type unions - for example, a createInvoice method might return Invoice|InvoiceError, such that you have two independent classes representing a successful invoice or providing details about why invoicing failed.

Bringing features from one language into another can sometimes make sense, but in this case, union types in PHP already work better than a generic result-type - they only really work well in languages that support generics, and in practice, a type union in PHP works much like the generic result-types in other languages anyway.

I would like to know what version of PHP are you running.

If you are using PHP 8, you can use match for this one. This way it's much closer to Rust.