On Mon, Apr 28, 2025, at 6:46 AM, Edmond Dantes wrote:
> Later in the letter you explain in more detail that this is *not a
> special kind of exception*, nor a new execution flow, but rather a*
> special type of result*.
>
> But if this is a special type of result, then it should follow *the
> same rules as all PHP types*. In other words, this cannot be solved
> without generics.
I do not understand that statement in the slightest. I have already
demonstrated how it can be solved without generics. Multiple response channels
from a function already exist: Normal returns and exceptions. Exceptions as
currently designed are just very poorly suited to the problem space I am
describing.
> However, the benefit of the new syntax, which could make the code
> cleaner, does not depend on generics:
> For example:
>
> ```php
> $res = someFunction() catch ($err) {throw $err;} // Like Zig?
> ```
A way to simplify try-catch syntax is certainly a possible side effect of this
feature, though that is secondary to the point I am making.
> However, it seems to me that we can achieve the same result using
> `throw`, simply by adding new syntax and capabilities. Yes, there may
> be some backward compatibility issues, but is it really something to be
> afraid of?
See other threads going on right now debating what BC breaks are acceptable and
which are not. And let's not forget that every release there is an outcry of
"OMG you broke my app!" for even the smallest deprecation of something widely
acknowledged to be bad practice anyway. We should absolutely not be flippant
about BC breaks in behavior.
--Larry Garfield
