On Wed, Feb 7, 2024, at 10:21 AM, Robert Landers wrote:
>> I think there's a subtle but important difference here between what you're
>> describing as the problem and what you implied the solution was (which I
>> then ran with).
>>
>> What you're talking about is trying to change the error handling model of
>> existing code without changing function signatures. There are only two
>> possible ways to do that, both of them bad: Unchecked exceptions and globals.
>>
>> What I described, based on the syntax you offered, is checked exceptions,
>> which necessarily means changing the function signature. Error handling is
>> part of the contract of a function. If its error handling changes, it
>> *should* have a signature change to indicate that. (That unchecked
>> exceptions do not do that is the problem with unchecked exceptions.) So if
>> "no changes to existing code" is the goal, checked exceptions as I describe
>> them are not the answer you are looking for.
>>
>> It seems from your latest message that you're describing more a generalized
>> version of `json_last_error()` and similar functions. The problem there is
>> that such an API design is generally considered very poor practice outside
>> of C, because it's all necessarily based on globals and "hope you remembered
>> to check the thing that no one told you to check and is not even slightly
>> obvious to check". That is not something I would want better support for in
>> the language at all. There's probably cleaner ways to emulate it in
>> user-space, but that is for a particular application to sort out. There's
>> definitely cleaner monadic solutions (which I've written before and are
>> quite neat) using a writer/logger monad, but that again doesn't meet your
>> "don't change existing code" requirement. I don't think anything the
>> language can do will meet that requirement and be a good design.
>>
>> --Larry Garfield
>
> Oh wow, this conversation got really interesting while I was asleep :D
>
> I think this could actually be interesting in a
> semi-backwards-compatible way, by just adding some syntax sugar:
>
> function getResult(): ?Result, ?ResultError {
> if($error) return null, $error;
> }
>
> instead of, but this would still work when destructuring:
>
> function getResult(): array {
> if($error) return [null, $error);
> }
>
> This would still work (the "backwards compatible" part):
>
> [$result, $error] = getResult();
>
> or this:
>
> $result, $error = getResult();
>
> Essentially, return types with a comma are just a "strongly typed
> array" and a comma on the left-hand side of assignment is just a
> destructure.
What you're describing here is basically porting Go multi-returns to PHP. That
is also an option, though I would probably not be in favor of it. For one, it
doesn't really offer much beyond the union returns we already have. For two,
it seems like it would necessitate nullable returns for both parts, which is a
hard-no from me on type safety. It's going to confuse static analyzers badly.
For three, the necessary idioms around Go's error handling are legendarily the
butt of jokes.
a, err := step_one()
if (err) {
return err
}
b, err := step_two(a)
if (err) {
return err
}
c, err := step_two(a, b)
if (err) {
return err
}
And so on. It's checked exceptions without the ergonomics. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
