Re: Request for RFC Karma – kha ledalamxyz

> 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: https://3v4l.org/YMLT1#v8.4.8 ``` 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

Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc