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
