On Jun 30, 2025, at 09:52, Khaled Alam <khaledalam.net@gmail.com> wrote:
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");
You mention “also empty strings and `"0"`” as quirks of ?:, but the argument you’re making is that `=>!` fails on “any falsy.” Empty strings and `"0"` are part of “any falsy,” so I’m a little confused about the distinction you’re making here.
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 expression
sendEmail( 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().
I don’t understand the distinction you’re making here, either. This seems to work currently with ?:
See here: Online PHP editor | output for YMLT1
function getUserEmail(): ?string { return 'foo@example.com'; }
function sendEMail(string $email) { echo "Email address is $email"; }
sendEmail( getUserEmail() ?: throw new Exception("Email required") );
Unless you mean it also *returns* the falsy value, which in this example doesn’t have much value, since it throws an exception, disrupting program flow.
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");
You’ll need to explain the “fluent” behavior in more detail. The way I read this is: if `$input["id"]` is falsy, throw an exception for the missing ID. If it’s not falsy, however, it should proceed to the `isValidId(...)` call, passing it the value. So, if the left hand-side is non-falsy, it skips over the immediate right-hand side?
If it skips over the immediate right hand side when the value on the left is non-falsy, then when it encounters the next `=>!`, the left-hand side is still non-falsy, so it shouldn’t attempt to call `isValidId(...)`, right?
Demonstration:<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!
Keep it up! Don’t let our criticism discourage you. 
A couple of pointers:
1. Don’t “top post” on replies to the mailing list.
2. It’s generally not a good idea to include images attached to mailing list messages.
Cheers,
Ben