Request for RFC Karma – khaledalamxyz

Hi,

I’d like to request RFC karma to create a new proposal titled "Fail-Fast Assertion Operator (|=>!|)".
About the Proposal:
The idea is to introduce a new fail_fast_assertion_operator to PHP that provides a concise and readable way to assert that an expression is valid and immediately fail otherwise.
Example 1:
$name = null;
$name =>! die("Missing name") > This is equivalent to:
if (!$name) {
die("Missing name");
}
Example 2:
$username =>! throw new Exception("Missing username");
$password =>! throw new Exception("Missing password");
is_valid($username, $password) =>! exit("Invalid credentials");
This is equivalent to:
if (!$username) {
throw new Exception("Missing username");
}
if (!$password) {
throw new Exception("Missing password");
}
if (!is_valid($username, $password)) {
exit("Invalid credentials");
}
The goal is to improve readability and reduce boilerplate in fail-fast validation scenarios. This is particularly useful in input validation, functional pipelines, and early guard clauses.
I’d like to open the discussion and collaborate with the community to refine and assess its value and implementation feasibility.
Please let me know if anything else is required from my side.

That seems to work today (https://3v4l.org/14aPa):

try {
$name ?? throw new Exception("variable is null or not defined");
} catch (Exception $e) {
echo $e->getMessage() . "\n";
}

try {
$name = '';
$name ?: throw new Exception("variable is falsy");
} catch (Exception $e) {
echo $e->getMessage() . "\n";
}

Regards,

Thomas

You can also use logical OR (||), similar to other languages:

$name || throw new Exception("variable is falsy");

Cheers,
Ben

Hi Ilija, Ben, and Thomas,

Thanks for the rapid feedback. You’re right that PHP’s existing
expression-throw idioms cover some use cases, but =>! fills three gaps:

1. Comprehensive “falsy” check =>! consistently treats all PHP-falsy
   values (null, false, 0, "", []) as failure, in a single, unambiguous
   operator.

// Existing: must choose between ??, ?:, ||, each with its own
quirks$name ?? throw… // only null$name ?: throw… //
also empty strings and "0"$name || throw… // can’t embed in
function call
// With =>!, you get exactly “fail on any falsy”:$name =>! throw new
Exception("Missing name");

2. Value forwarding

All of the above patterns discard or ignore the original value when used
inline. With =>!, the guarded value is both asserted and returned, so
you can write:

// Inline validation + use in one expressionsendEmail( getUserEmail()
=>! throw new Exception("Email required") );

This both throws on a missing/falsy email and — when valid — passes the
exact email string through to sendEmail().
3. Clean, declarative syntax

Because it’s a dedicated operator rather than a hacky boolean trick, =>!:

Reads as “take X, or fail” in one glance.

Avoids parentheses gymnastics or confusing operator precedence.

Encourages fluent, lets you chain guards:

$userId = $input["id"] =>! throw new Exception("ID missing")
=>! isValidId(...) =>! throw new Exception("Invalid ID");

Demonstration:
[image: image.png]

This was primarily an exercise to familiarize myself with the internals
process. I’d love to gather feedback - and some RFC-karma - before drafting
a full proposal on the mailing list.

Thanks again for your time and guidance!

Regards,
Khaled

Hi Khaled

On Mon, Jun 30, 2025 at 1:03 AM Khaled Alam khaledalam.net@gmail.com
wrote:

I’d like to request RFC karma to create a new proposal titled "Fail-Fast
Assertion Operator (=>!)".

$name =>! die("Missing name");
This is equivalent to:
if (!$name) {
die("Missing name");
}

As mentioned by the other responses, given that throw is an expression
you can already achieve this through various operators:

// Throw is $name is null
$name ?? throw new Exception();
// Throw if $name is empty
$name ?: throw new Exception();
// Throw if $name is falsy
$name || throw new Exception();
$name or throw new Exception();
// Throw if $name is truthy
$name && throw new Exception();
$name and throw new Exception();

It's not clear in what way your proposal is different. Hence, I'm
pausing the granting of RFC karma until these details are clarified.

Cheers