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