Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125321
Feedback-ID: id5114917:Fastmail
Date: Tue, 27 Aug 2024 15:14:04 +0100
To: internals@lists.php.net, Bilge <bilge@scriptfusion.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
User-Agent: K-9 Mail for Android
In-Reply-To: <ff8af596-6660-4871-8aad-60fc392189e0@scriptfusion.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com> <ddc026b1-3cfd-03fe-1cd3-3a6930ed2c22@php.net> <ff8af596-6660-4871-8aad-60fc392189e0@scriptfusion.com>
Message-ID: <B2BAE1A6-D2A1-49F6-85A0-CD83E07ACB75@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 27 August 2024 14:14:03 BST, Bilge <bilge@scriptfusion=2Ecom> wrote:
> Whilst the applications beyond use in conditionals still strikes me as l=
imited, it also appears equally harmless=2E=C2=A0 Though the number of peop=
le 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 ar=
e harmless=2E=20

I'm slightly baffled why you're still looking at it from this angle=2E Pos=
sibly, the volume of messages in the thread has made it easy to miss some o=
f the points that have been raised=2E

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 sub=
classes or future versions=2E It makes changes that are currently guarantee=
d safe by the principles of the language, into compatibility breaks=2E As B=
ruce pointed out, it introduces a contravariant output, contrary to the sub=
stitution principle, unless we break a bunch of existing use cases by decla=
ring parameter defaults invariant=2E

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 particula=
r operators that are the problem, it's the entire principle of allowing "de=
fault" to be evaluated to a value in the middle of an expression=2E

The only expressions that are in some sense "safe" are those that can appl=
y equally to any possible type that the function could in future set as the=
 default=2E In theory, that includes a match statement with an arm of "defa=
ult =3D> default", e=2Eg=2E

json_encode($data, default, match(gettype(default)) { 'int' =3D> default |=
 JSON_PRETTY_PRINT, default =3D> 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"=2E

So that leaves us with those expressions where "default" is only a result,=
 not an input:=20

expression ?: default
expression ? expression : default=20
expression ? default : expression
expression ?? default

Unless I've forgotten something, that's it; that's your list of allowed ex=
pressions=2E

Whether that's possible to enforce, in the parser, the compiler, or the ex=
ecutor, I don't know=2E But if it's not, my opinion is that the entire feat=
ure has an unanticipated problem that makes it unworkable=2E It would be a =
shame, because on the face of it I can see the value, but sometimes you jus=
t hit a dead end and have to turn back=2E

Regards,
Rowan Tommins
[IMSoP]