On 27 August 2024 14:14:03 BST, Bilge <[email protected]> wrote:
> Whilst the applications beyond use in conditionals still strikes me as limited, it also appears
> equally harmless. Though the number of people whom feel its use in expression should be limited is
> steadily growing, I'm still waiting on someone to publish an exclusion list with justification
> for each exclusion, because again, I think a plurality of possibilities are harmless.
I'm slightly baffled why you're still looking at it from this angle. Possibly, the volume
of messages in the thread has made it easy to miss some of the points that have been raised.
There is a fundamental, unavoidable, cost to allowing any expression which relies on the type or
value of the parameter's default not changing in subclasses or future versions. It makes
changes that are currently guaranteed safe by the principles of the language, into compatibility
breaks. As Bruce pointed out, it introduces a contravariant output, contrary to the substitution
principle, unless we break a bunch of existing use cases by declaring parameter defaults invariant.
You're not going to see any kind of "exclusion list"of operators, because on closer
examination of the impact, we've realised that it's not particular operators that are the
problem, it's the entire principle of allowing "default" to be evaluated to a value
in the middle of an expression.
The only expressions that are in some sense "safe" are those that can apply equally to any
possible type that the function could in future set as the default. In theory, that includes a match
statement with an arm of "default => default", e.g.
json_encode($data, default, match(gettype(default)) { 'int' => default |
JSON_PRETTY_PRINT, default => default });
Apart from being incredibly hard to read, that's not even useful: the aim is to always enable
pretty printing, but the result is "enable pretty print, unless the type of the default happens
to change".
So that leaves us with those expressions where "default" is only a result, not an input:
expression ?: default
expression ? expression : default
expression ? default : expression
expression ?? default
Unless I've forgotten something, that's it; that's your list of allowed expressions.
Whether that's possible to enforce, in the parser, the compiler, or the executor, I don't
know. But if it's not, my opinion is that the entire feature has an unanticipated problem that
makes it unworkable. It would be a shame, because on the face of it I can see the value, but
sometimes you just hit a dead end and have to turn back.
Regards,
Rowan Tommins
[IMSoP]