Re: [PHP-DEV] Request for RFC Karma – khaledalamxyz

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

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.

···

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!

Regards,
Khaled

(Attachment image.png is missing)

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. :slight_smile:

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