On Sun, Aug 25, 2024, at 16:58, John Coggeshall wrote:
>
>
>> If the underlying API changes the argument type, consumers will have an issue regardless.
>> For those cases where the expression is simply default, you'd actually be
>> protected from the API change, which is a net benefit already.
>>
>> This also protects the user from changes in the argument names.
>
> As I said, I don't have a particular problem with default as a keyword to
> express "whatever the default value might be in the function declaration", but I do have
> some real concerns about its use as an operand in an expression. The RFC provides for a single valid
> use case of operators (i.e. things like default | JSON_PRETTY_PRINT ), yet calls for a
> huge array of valid operations, many of which the RFC itself notes don't make much / any
> sense. I'd personally like to see this RFC dramatically reduce the scope of operations
> supported with default as an operand initially (e.g. perhaps only bitwise ops), and
> revisit additional operations as needed down the road. IMO there is a very small subset of all PHP
> operators that make any sense at all in this context, and even fewer that I think are a good idea to
> allow even if they might make some sort of sense.
Which operants don’t make sense?
— Rob