On 27 August 2024 05:20:32 BST, John Coggeshall <j...@coggeshall.org> 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]
