Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108427
To: Nikita Popov <nikita.ppv@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Planning an RFC to allow calls to global functions in
 constant expressions
Thread-Index: AQHV2VGmZkZM3HvoRkWNVub65jMyhKgOEEuAgAP0j88=
Date: Sun, 9 Feb 2020 00:55:26 +0000
Message-ID:
 <DM5PR07MB30673AFAFFA09C586BA173F9F91F0@DM5PR07MB3067.namprd07.prod.outlook.com>
References:
 <DM5PR07MB3067CC1E175A76EB46AE1649F9060@DM5PR07MB3067.namprd07.prod.outlook.com>,<CAF+90c9XeU9emWM1XBoM5a-OzHKubLJ-Y57dBFQ1B-zDbjWL1w@mail.gmail.com>
In-Reply-To:
 <CAF+90c9XeU9emWM1XBoM5a-OzHKubLJ-Y57dBFQ1B-zDbjWL1w@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [MtzB5GEUFMQxC/0xJumjNQdoQdP8rfqs]
x-ms-publictraffictype: Email
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 8e2c8ce0-0fb0-4634-03a1-08d7acfac08b
x-ms-traffictypediagnostic: DM6NAM12HT142:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 z9yrmN5T91j7xvIlOx1U8TFSNma7Pq9qlLY18OER/JoPXSTpSM0Fdp4mfRxG2syOizBEbkrQbfzTR/CGBZJ1k6z0FQ/ucjMKotp8u4CBNIi0o15CVw9iXCl9fgh2V88W73sVHOK7OqI6SMnvOTanSgBmER219AjL+FqQQ5gIyV85qLUJGn5c0uERZuQVUN2R
x-ms-exchange-antispam-messagedata:
 SODCNEGGJ9ROt43AyQSy3HNSA5+rPEeK7supdokTgdSCHeo2lozUzBiCjjC3UiiGVSZZIMK469joJrKg1WzMS32rmFnPVh92meJA5LiqROxrIwbBRxryr484qxH3W3b8YKInlbEhN6hxhWxQowPDYw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e2c8ce0-0fb0-4634-03a1-08d7acfac08b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2020 00:55:26.7612
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM12HT142
Subject: Re: [PHP-DEV] Planning an RFC to allow calls to global functions in
 constant expressions
From: tysonandre775@hotmail.com (tyson andre)

> As you've already realized, the main problem here is the behavior for=0A=
> functions that have side-effects or state. Currently we mostly get away=
=0A=
> with the illusion that it doesn't matter when exactly constexpr=0A=
> initializers are evaluated. Apart from the error location and (admittedly=
=0A=
> quite a few) other details, you ostensibly can't distinguish whether the=
=0A=
> expression is going to evaluated on declaration, on first access or on ea=
ch=0A=
> access.=0A=
=0A=
Good point - If PHP ends up supporting an option where **any** global funct=
ion can get called,=0A=
It'd make sense to evaluate any expression *with a function call*=0A=
every time for instance properties and parameter defaults=0A=
(e.g. `public $id =3D generate_unique_int_id()`).=0A=
(the optimizer can later optimize any functions where it won't be noticeabl=
e).=0A=
=0A=
I think that would require updates to my PR for caching,=0A=
since immutable returned zvals (including false/true) get cached permanentl=
y.=0A=
=0A=
> I'm not a big fan of whitelisting functions, especially as this runs into=
=0A=
> the name resolution issue (you suggest that essentially the use of fully=
=0A=
> qualified/imported names will be forced -- unlike everywhere else in PHP)=
,=0A=
> and because I've seen this "mark all the functions const/constexpr" race=
=0A=
> play out one too many times in other languages, which have a much stronge=
r=0A=
> motivation for it than we do.=0A=
=0A=
I'd agree with all of those drawbacks of whitelisting functions.=0A=
This is still the best compromise I can think of for allowing those functio=
ns=0A=
I've mentioned, if it turns out there are too many objections to this=0A=
making constants too dynamic.=0A=
=0A=
> If we want to expand the allowed operations inside constexpr initializers=
,=0A=
> I think this needs to start by considering precise evaluation semantics i=
n=0A=
> the places where it matters. Those are primarily initializers for functio=
n=0A=
> parameters and non-static properties, because both of these have a=0A=
> reasonable expectation of evaluation at each use. I think the best way to=
=0A=
> approach those two may well be to relax the constexpr restrictions on the=
m=0A=
> entirely (allowing say "public Foo $prop =3D new Foo()", something people=
=0A=
> want anyway) and make sure that things are evaluated on each access (unle=
ss=0A=
> they can be pre-evaluated without affecting behavior, of course).=0A=
=0A=
For a more general proposal, the variable scope is a potential problem.=0A=
For example, would the below example create a new class definition every ti=
me f() was called?=0A=
(Creating a brand new scope with no variables,=0A=
allowing everything except variables (and relying on zend_forbid_dynamic_ca=
ll to blacklist get_defined_variables()),=0A=
or always using the global scope might be ways of handling this.)=0A=
=0A=
```=0A=
function f($x) {=0A=
    return fn() =3D> new class() {=0A=
        public $var =3D $x;  // or new Foo($x)=0A=
    };=0A=
}=0A=
$factory1 =3D f(1);=0A=
$factory2 =3D f(2);=0A=
```=0A=
=0A=
That reminds me:=0A=
I forgot about functions such as `compact()`, `extract()` and `get_defined_=
vars()`.=0A=
(and `func_num_args()`/`func_get_args()`/`func_get_arg()`).=0A=
It looks like all of them check `zend_forbid_dynamic_call()` to throw,=0A=
but I need to add tests and possibly flag the call as dynamic.=0A=
=0A=
> For the remaining cases (constant, class constant and static property=0A=
> initializers) we can probably get away with the current semantics, which =
is=0A=
> evaluation on first access, with a very broad definition of what "access"=
=0A=
> means.=0A=
=0A=
Agreed - I plan on keeping the existing semantics for those,=0A=
but I think the semantics of global(non-class) constants are that=0A=
they are currently always evaluated immediately, based on the tests I've wr=
ote for this RFC.=0A=
=0A=
Thanks,=0A=
- Tyson=