On 27 August 2024 05:20:32 BST, John Coggeshall <[email protected]> wrote:
>> I DO think there are likely whole categories of expressions we can likely say
>> "no" to - anything where the default represents a union type (and _mixed_ is a union type)
>> should likely only allow default by itself or as a bare value on the RHS of an expression.
I don't think having additional restrictions on union types makes much difference, because even
if a signature doesn't use union types now, it can be extended to do so at any time, either in
terms of inheritance or evolution in a new version.
It is a well understood principle that widening the type of an input cannot break existing uses, and
relying on the concrete type of the default will remove that guarantee.
While the example of bitwise or in the RFC looks appealing, I am no longer sure I can even support
that, because it has the same problem - in a future version of PHP, json_encode might change to
take int|JsonOptions, with a default value that is an object not an int. Code passing an integer
won't break, code accepting the default won't break, but code using "default |
JSON_PRETTY_PRINT" will immediately get a TypeError. With the feature in place, such an
evolution, which was previously safe, would become a hard BC break.
Forbidding that evolution, not just to that example, but to every function or method with any
default parameter, is too high a price to pay for the benefit we'd get.
Regards,
Rowan Tommins
[IMSoP]