Re: [RFC] Default expression

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