On 27 August 2024 14:14:03 BST, Bilge <bi...@scriptfusion.com> 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]
