> On Jun 30, 2025, at 09:52, Khaled Alam <khaledalam....@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 'f...@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
signature.asc
Description: Message signed with OpenPGP
