[PHP-DEV] PHP 8.0.8RC1 Available for testing

[Gabriel Caruso]

PHP 8.0.8RC1 has just been released and can be downloaded from:
https://downloads.php.net/~pollita/ (thanks Sara for uploading everything)
Or use the git tag: php-8.0.8RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net
8.0.8 should be expected in 2 weeks, i.e. on July 1st 2021.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/carusogabriel/0e61cfc58efd2bd4932eff9ec79730b1

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.8RC1.tar.gz
SHA256 hash:
e6092620eb3da03644b7b4fe5dc0a16e7e9d04de383e3858124afb3a8cb3fe3c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDIUX0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj9snD/9BiH/2eh5ZS8R73cect0kxb3ey
50eVf/4yEmo5rPCcNuyWuga9OhTXYDiHUaZCnAPZFbVZwh8krBZdS4OfbPeQh8Ei
7QUyyadjGlUQ2OPBqa0zDT6f+fURG6BgY+u6o4NlAmDANOrS7KSV7TbWEVJRdiOp
SyK+ymDS+nOLyPUaMFgGloeyTEW7l5n1461jTwgFdUOZT9EEeurzkKmsm9sdYVs1
K3lfDLdNOG+uch/ixLjU9ZNVw5JLuDCWlB7rPaBFbzxhchOr7CNGG/Y0JUYYnpW+
Y1pkGvUtqSLUB8ta+tT2Ty8aQ7ZvNj8/GpKDGzYN+spvrwbqyGvzn2W16lnHfKP4
rWVzKL8jlX892qkCjeJS6sApM/JNxkNKizMzx3iVHVkUYV43i7FMg8d0FhP45xq4
MDIhgXIYiCokxfRUIiKzko8fQPSFuhFy81IckhEok07ofTqeptwZNJOM95dJh5A8
kEAI/xnKYJAPx8zEHfUontGlQ2F2qqVerBdHo9X5tqQXmTNU98PSD47sgxUjgAER
SiNhXs2CNQVvBb3i4dWEIIjdJq/lKC0W5WIqPPPd77SnTdH5ibyTtkeTEnwv56c4
1VnVAwfgQRTPS5KswO6FnuI8tb6MYWRAuZEqJLe3O5/aYpkD0gt/heVi/3A+wfss
Xp+vnpOwIwpot1vTmA==
=D5BY
-END PGP SIGNATURE-

php-8.0.8RC1.tar.bz2
SHA256 hash:
bcb8a0127674a6f51b062ec553a6d7fb031640e3a94094ad5b9e9302d365b21a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDIUYIWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj/5jD/9lLQ+rvRWy/a3K41Dw69RBe3T5
HAdoFGNhmpnItsuDT2NfSZs9JwEHgYM1yxX1WaJPYfvjMKlnR+QFKShdDbznjMbn
rRXPpzXozGA9VYfV3ztp8eyAIkY4d1EfTREtn/v6aCRepNJ5wHTIIm/n9GB6tKG5
QYTzzgov0YE/RXdhxnYL359J7ICcv4ormXnr5Os2SKusAYK4ZSsNkjmGjGhcBURu
OnYLQx4OFkRLes2uL3opMlKeDl9zOyT0t9znZA/Ydak4fUDzZsasWrkf4ddjPOa0
9bRNp+gPlJqLxSsnHdbRiH6hMAyk6CAZSocB8VPi9QNQXxj0CwAiunWXTaRkUZvy
nTXVIsK5KeHvKMivvyw0o8Cy5EXgHOG1OXcHKjFU9X4rcdTLWfoMToavlMuezLMb
uZ2i1JE6KDmrewfvOsaVRj2gvJR6yMxfGEf47+yt/J0odbmK/UDJI3UHotacPT0H
ri1Gn+HdkZRMZangFsl0M+40puxwbvLs0E1k7ve6FA1Y2ul2Rg3avm0i+v3+U3dJ
cmHAIwxBPJus6gbUKsq1EnnleXJPDXKOTequn6/+2k5NUYe5eVy6Nh0jvuhNqlHb
f9yIZ6B9lGfA16jQQhHMYx472ufrhhr90V/PyNWIMf1s6Nd8E6xEryfLvwgCcXAv
yzSQWRYnJyG26A1Z2A==
=1Vlp
-END PGP SIGNATURE-

php-8.0.8RC1.tar.xz
SHA256 hash:
cbae837b40ad2a936dc26b7d03f0763db8961ab5b481ba232faefa104982198a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmDIUYMWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj5oVEACkh0eH5soZLPs3UoBV5ZnWAZp5
8bkLlnebjK6sAqIdAl9Z5V5JRvczEkBpA7DxyW+AFfhJ7K0J5HfLgm+Mwgn/zF6R
RxMsHnStkKLfKmjgQMzUEwywT55W5cEfDXM5iOt62h896lbiT++6VC0UUuaBBmpZ
hS6/NOZAOGmUCRdg1rOpi1whmqKlsQ6A0hK2ENxiEZHy4fV5hxT+ME98ZfNUB5ol
Oq1vjEmne/+EGuAEF8IC3GjbmK17WBpNN21mwdRZbmyedAEASOz/5oMkxQd4w7CJ
BGjoDMpc8AKLGVoKUFP25lGHohpO+z3wacxZr92Rz9Bf32Hhtqeowk8oVQpaKcfQ
jH0nWUiOk8dyCT/t9LhqJBT0mHCzKO4/uNzhVq7etOkgU8XhncjoODP1HLiu16Ns
JF5aiy3wdFgjeXmzVuMqZkls2v1frQws2JTSj9LoUwrqSFxfwn5Q3DJIGD0JEmKq
72MclxTEXmfBWDpfq/C0AoBDQsATdbqDBVAEea+4YiTqTD5npQUS7NiuMwyEnguP
NJRVymY6I6iok66r8PbaIdSUVZeY43uq6eRAtlsQLN2ufWfTaPufee0NkNUxQgW/
EH8AclHImbcnawWZC8MeiRd1a2B3k4aj8lOSoRzL3gMb0ts06LCdIwKg6aocaPvb
H+ztYU7V5P9H9mbaWg==
=sgJ1
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2

[Mark Tomlin]

Please excuse the year long bump, but I was hoping to draw some more
attention to the implicit "match (true)" case. I'm just a regular user of
PHP, nothing too fancy, just one of the many, many people around the world
who use PHP. When I first started using match statements, I thought it was
a natural thing that an implicit "match (true)" would just work. I do hope
that this makes it into PHP 8.1, as that seems like the most obvious next
step here and it would be nice for it to make it into the very next release.

That is all. Thank you very much to Ilija Tovilo for adding the match
keyword to the language, and the whole PHP dev team for making this
incredible language. PHP has given me a whole career, and I am deeply
grateful to you all.

On Fri, May 22, 2020 at 11:30 AM Larry Garfield 
wrote:

> On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote:
> > Hi internals
> >
> > I'd like to announce the match expression v2 RFC:
> > https://wiki.php.net/rfc/match_expression_v2
> >
> > The goal of the new draft is to be as simple and uncontroversial as
> > possible. It differs from v1 in the following ways:
> >
> > * Blocks were removed
> > * Secondary votes were removed
> > * optional semicolon
> > * omitting `(true)`
> > * Unimportant details were removed (e.g. examples for future scope)
> >
> > You can look at the diff here:
> > https://github.com/iluuu1994/match-expression-rfc/pull/8/files
> >
> > I will also leave the discussion period open for longer as that too
> > was one of the primary criticisms.
> >
> > As mentioned by Kalle:
> >
> > > Resurrecting rejected RFCs have a "cooldown" of 6 months:
> > > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> >
> > That is, unless:
> >
> > > The author(s) make substantial changes to the proposal. While it's
> > > impossible to put clear definitions on what constitutes 'substantial'
> > > changes, they should be material enough so that they'll significantly
> > > affect the outcome of another vote.
> >
> > Given that many people have said without blocks they'd vote yes I'd
> > say this is the case here. Let me know if you don't agree.
> >
> > Ilija
>
> I'd say this is a textbook example of sufficiently "substantial."
>
> Thanks, Ilija!  This looks a lot better.
>
> My one question is why you're not including the implicit "match (true)" in
> this version, when the secondary vote on the previous RFC was 80% in favor
> of it.
>
> (And I still think the argument is stronger if you include a comparison to
> ternary assignment, but that doesn't affect implementation.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Thank you for your time,
Mark 'Dygear' Tomlin;

Re: [PHP-DEV] [VOTE] Pure intersection types

[G. P. B.]

On Thu, 3 Jun 2021 at 20:31, G. P. B.  wrote:

> Hello internals
>
> I've opened the vote for the "Pure intersection types" RFC:
> https://wiki.php.net/rfc/pure-intersection-types
>
> It will run for 2 weeks and end on the 17th of June 2021
>
> Best regards,
>
> George P. Banyard
>

The vote is now closed with 30 votes in favour and 3 against.
This corresponds to a 90% approval rate meaning the RFC has been accepted.

Best regards

George P. Banyard

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

[tyson andre]

Hi Larry Garfield,

Thanks for responding.

> While I like the idea of an immutable collection, and the performance boost 
> seems useful, this proposal seems to go about it in a sloppy way.
> 
> 1) Iterable doesn't seem like the right "family" for this.  It is iterable, 
> but so are lots of other things.

I'd suggested alternative names such as ImmutableKeyValueSequence, in 
https://externals.io/message/114834#114834 , but

- It seemed as if the sentiment was very strongly against long names. I likely 
misjudged this.
- Many names were suggested by only one person. I can't tell if there's a 
consensus from that. E.g. `*Aggregate`.
- When I suggested names such as `ImmutableKeyValueSequence` before starting 
the vote, nobody had any feedback of it being better/worse than my previous 
proposals.

> 2) I... have never seen anyone in PHP use "pairs" as a concept.  I have no 
> idea what they're doing here.

https://www.php.net/manual/en/class.ds-pair.php is a concept used in the DS 
PECL, e.g. https://www.php.net/manual/en/ds-map.first.php
Proposing that as a new object type seemed excessive here.

That reason is because PHP is (fairly) unique among languages with generic 
iterable types in that there's a key associated with values.
I had to deal with this unusual situation somehow, and it's not a surprise that 
the solution is also unusual.
Do you propose alternate solutions other than omitting the functionality?

- Javascript only provides values in .next() - 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols
- Python only provides values 
https://docs.python.org/3/glossary.html#term-iterable
- C++ iterators only provide values 
https://www.cplusplus.com/reference/iterator/
- And so on

A generator-based workaround would be much slower

```
function userland create_iterable(iterable $pairs) {
foreach ($pairs as [$key, $value]) {
yield $key => $value;
}
}
// $pairs = array_map(...array_filter(...fetchOrComputeData(...)...)
$iterator = new ImmutableKeyValueSequence($pairs);
```

The other reason is that php has a large collection of internal and 
user-defined functions for dealing with arrays (sorting, filtering, etc), but 
few for iterables.
toPairs and fromPairs allow easily converting values to this and back, then 
calling usort/filter for compact code.

And if I provided fromPairs, toPairs seemed to make sense for completeness.

> 3) The JsonSerialize seems out of place.  It may make sense from another 
> angle, but it just sorta appears out of nowhere here.
> 
> It almost feels like what you actually want is an immutable Dictionary class. 
>  Such would naturally be iterable, countable, serializing makes some sense, a 
> fromIterable() method would make sense, etc.  

It would be useful for some but not all use cases. Especially use cases where 
keys aren't hashable, or where keys are repeated.

Not all values would be hashable in a dictionary (e.g. circular data 
structures, self-referential arrays). 

There's a lot of open design questions for Dictionary in core, e.g. the name, 
and whether objects should be hashable, or namespace, or whether it may 
conflict with future native types.
- And if a Hashable magic method or interface was added, then that might throw 
and make it impossible to store a generator.
- And if large data structures are used (e.g. yielding extremely large keys or 
slow object hashing, the hashing would be slow even when the application didn't 
need hashing at all)

> That I could get behind, potentially, although it also runs into the exciting 
> question of type restrictions and thus generics, which is where list type 
> discussions go to die. :-)

That's another possible obstacle to dictionary in core, but I hope not.

Thanks,
Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Larry Garfield]

On Thu, Jun 17, 2021, at 9:45 AM, Côme Chilliet wrote:
> Le Thu, 17 Jun 2021 08:37:23 -0500,
> "Larry Garfield"  a écrit :
> 
> > On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> > > > $c = stuff(...);
> > > > $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)  
> > > >   => stuff($i, $s, $f, $p, $m);  
> > >   
> > > > $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> > > > $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);  
> > > 
> > > Why is there an additional variadic parameter in this one?  
> > 
> > ... means "zero or more".  In this case, it means zero, that is, it creates 
> > a
> > closure that requires no arguments and will call the original function with
> > all of the provided values later.  This is the "deferred function" use case
> > mentioned further down.
> 
> I still do not understand why there is an added variadic parameter when
>  using ... in stuff(1, 'hi', 3.4, $point, 5, ...); but not when using it in
>  stuff(...);
> What happens when we use stuff(1, 'hi', 3.4, $point, ...); ?
> 
> > > Also, in the second set of examples:  
> > > > function things(int $i, float $f, Point ...$points) { ... }  
> > >
> > > > // Ex 13
> > > > $c = things(...);
> > > > $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);  
> > >
> > > > // Ex 14
> > > > $c = things(1, 3.14, ...);
> > > > $c = fn(...$args) => things(...[1, 3.14, ...$args]);  
> > > 
> > > What happens to the typing of the variadic parameter here? Why is it
> > > removed?
> > > 
> > > It would feel natural that the ... means "copy the rest of the parameters
> > > from signature". Here it seems it sometimes mean that, and sometimes mean
> > > "accept an additional variadic parameter and pass it along".  
> > 
> > Internally placeholders do mean the former.  A trailing variadic, though, 
> > can
> > accept extra arguments of potentially not pre-defined types, so it sort of
> > straddles the line.  Variadics make things weird. :-)  (Dating from PHP
> > 5.6.)  In the majority case, though, thinking of them as "copy the rest of
> > the arguments" is accurate.
> 
> I do not understand why Points ...$points becomes untyped ...$args when using
>  things(...), while when using stuff(...) earlier no typing was lost.

The type information is not lost.  The examples are not exact equivalents, but 
approximate equivalents.  Joe confirmed that the closure that's generated 
really does retain the type information:

krakjoe@Fiji:/opt/src/php-src$ cat wat.php
 partial function things ] {
  @@ /opt/src/php-src/wat.php 4 - 4

  - Parameters [3] {
Parameter #0 [  int $i ]
Parameter #1 [  float $f ]
Parameter #2 [  Point ...$points ]
  }
}

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Thu, 17 Jun 2021 08:37:23 -0500,
"Larry Garfield"  a écrit :

> On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> > > $c = stuff(...);
> > > $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)  
> > >   => stuff($i, $s, $f, $p, $m);  
> >   
> > > $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> > > $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);  
> > 
> > Why is there an additional variadic parameter in this one?  
> 
> ... means "zero or more".  In this case, it means zero, that is, it creates a
> closure that requires no arguments and will call the original function with
> all of the provided values later.  This is the "deferred function" use case
> mentioned further down.

I still do not understand why there is an added variadic parameter when
 using ... in stuff(1, 'hi', 3.4, $point, 5, ...); but not when using it in
 stuff(...);
What happens when we use stuff(1, 'hi', 3.4, $point, ...); ?

> > Also, in the second set of examples:  
> > > function things(int $i, float $f, Point ...$points) { ... }  
> >
> > > // Ex 13
> > > $c = things(...);
> > > $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);  
> >
> > > // Ex 14
> > > $c = things(1, 3.14, ...);
> > > $c = fn(...$args) => things(...[1, 3.14, ...$args]);  
> > 
> > What happens to the typing of the variadic parameter here? Why is it
> > removed?
> > 
> > It would feel natural that the ... means "copy the rest of the parameters
> > from signature". Here it seems it sometimes mean that, and sometimes mean
> > "accept an additional variadic parameter and pass it along".  
> 
> Internally placeholders do mean the former.  A trailing variadic, though, can
> accept extra arguments of potentially not pre-defined types, so it sort of
> straddles the line.  Variadics make things weird. :-)  (Dating from PHP
> 5.6.)  In the majority case, though, thinking of them as "copy the rest of
> the arguments" is accurate.

I do not understand why Points ...$points becomes untyped ...$args when using
 things(...), while when using stuff(...) earlier no typing was lost.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] is_literal

[Mike Schinkel]

> On Jun 16, 2021, at 1:24 PM, Craig Francis  wrote:
> 
> On Sat, 12 Jun 2021 at 18:00, Craig Francis 
> wrote:
> 
>> I'd like to start the discussion on the is_literal() RFC:
>> https://wiki.php.net/rfc/is_literal
>> 
> 
> Hi Internals,
> 
> Following up on the is_literal() RFC, thanks for the feedback. It looks
> like there are only 2 minor open issues - updating the implementation to
> allow integers, and what to call the flag/function.
> 
> Matthew Brown wants to support integer values, simply because so much code
> already includes them, and I cannot find a single way that integers alone
> can cause issues from an Injection Vulnerability point of view (but if
> anyone can, I absolutely welcome their input). Other variable types like
> floats and booleans will still be excluded (because the value you put in
> often is not what you get out, e.g. true/TRUE being converted to "1").
> 
> Which leads us to the name, because "is_literal" may be, uh, too literal.
> So can we come up with something better?
> 
> It needs to be a name that suggests: This variable contains programmer
> defined strings, integers, and interned values (as noticed by Claude Pache
> and Rowan Tommins). Ideally staying in the standard convention of
> ‘is_singleword’.
> 
> Joe has suggested is_known(), where "we have the concept of known strings
> internally", which I like (though might clash with more userland functions
> than ‘is_literal’). Last night I also wondered about `is_constrained()`, as
> the value has limited sources. But I'd also welcome more suggestions, and
> am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion).

"is_trusted()" comes to mind, inspired by Javascript's Trusted Types API[1].

That way in the future it could validate other trusted types besides just 
literals and integers when and if an agreement on what should be trusted 
becomes clear 

Another plus with the semantics is in many cases the library developer who used 
is_trusted() would not need to update their code to support these newly trusted 
types, e.g. literal-string types, "trusted" classes with a __ToString() method, 
etc.

-Mike

[1] https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

[Larry Garfield]

On Wed, Jun 16, 2021, at 12:09 PM, Levi Morrison via internals wrote:
> > Over half of the objections are to functionality, over half to unspecified 
> > reasons,
> 
> I support people choosing not to directly respond with their
> unspecified reasons, but if anyone is open to sharing I would
> appreciate them doing so. I agree with Nikita that the concept is
> useful, and with some refinement it could be more acceptable to
> voters. If we know more about these "unspecified reasons" then perhaps
> we can improve something for them as well.
> 
> A guess: they don't really want unproven data structures going into
> core, well, because you see the state of some (many) of the SPL data
> structures.

While I like the idea of an immutable collection, and the performance boost 
seems useful, this proposal seems to go about it in a sloppy way.

1) Iterable doesn't seem like the right "family" for this.  It is iterable, but 
so are lots of other things.

2) I... have never seen anyone in PHP use "pairs" as a concept.  I have no idea 
what they're doing here.

3) The JsonSerialize seems out of place.  It may make sense from another angle, 
but it just sorta appears out of nowhere here.

It almost feels like what you actually want is an immutable Dictionary class.  
Such would naturally be iterable, countable, serializing makes some sense, a 
fromIterable() method would make sense, etc.  That I could get behind, 
potentially, although it also runs into the exciting question of type 
restrictions and thus generics, which is where list type discussions go to die. 
:-)

So it's not the concept I'm against; the angle of attack here feels sloppy and 
coming at the problem from the wrong angle.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Larry Garfield]

On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> Le Wed, 16 Jun 2021 11:16:28 -0500,
> "Larry Garfield"  a écrit :
> 
> > Hi folks.  The vote for the Partial Function Application RFC is now open, 
> > and
> > will run until 30 June.
> > 
> > https://wiki.php.net/rfc/partial_function_application
> 
> I do not understand how this ... placeholder works, it feels inconsistent.
> 
> From the examples:
> 
> > $c = stuff(...);
> > $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)
> >   => stuff($i, $s, $f, $p, $m);
> 
> > $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> > $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);
> 
> Why is there an additional variadic parameter in this one?

... means "zero or more".  In this case, it means zero, that is, it creates a 
closure that requires no arguments and will call the original function with all 
of the provided values later.  This is the "deferred function" use case 
mentioned further down.

> Also, in the second set of examples:
> > function things(int $i, float $f, Point ...$points) { ... }
>  
> > // Ex 13
> > $c = things(...);
> > $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);
>  
> > // Ex 14
> > $c = things(1, 3.14, ...);
> > $c = fn(...$args) => things(...[1, 3.14, ...$args]);
> 
> What happens to the typing of the variadic parameter here? Why is it removed?
> 
> It would feel natural that the ... means "copy the rest of the parameters from
>  signature". Here it seems it sometimes mean that, and sometimes mean "accept 
> an
>  additional variadic parameter and pass it along".

Internally placeholders do mean the former.  A trailing variadic, though, can 
accept extra arguments of potentially not pre-defined types, so it sort of 
straddles the line.  Variadics make things weird. :-)  (Dating from PHP 5.6.)  
In the majority case, though, thinking of them as "copy the rest of the 
arguments" is accurate.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Larry Garfield]

On Thu, Jun 17, 2021, at 3:01 AM, Côme Chilliet wrote:
> Le Wed, 16 Jun 2021 11:16:28 -0500,
> "Larry Garfield"  a écrit :
> 
> > Hi folks.  The vote for the Partial Function Application RFC is now open, 
> > and
> > will run until 30 June.
> > 
> > https://wiki.php.net/rfc/partial_function_application
> 
> From the RFC:
> 
> > The ? character was chosen for the placeholder largely because it was
> > unambiguous and easy to implement. Prior, similar RFCs (such as the original
> > Pipe Operator proposal from several years ago) used the $$ (lovingly called
> > T_BLING) sigil instead. So far no compelling argument has been provided for
> > changing the character, so the RFC is sticking with ?. 
> 
> The main argument for $$ is to be able to have partial methods with $$->, this
>  should be stated in this paragraph.

That's not something that was ever brought up in the discussion.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Thu, Jun 17, 2021 at 11:14 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:

> Le mer. 16 juin 2021 à 13:47, Larry Garfield  a
> écrit :
>
> > On Wed, Jun 16, 2021, at 3:16 AM, Nikita Popov wrote:
> >
> > > > Arguments and attributes are enough to justify this RFC on its own,
> > but is
> > > > there a way we can resolve the static property question?  Right now
> > the RFC
> > > > says "these initializers are evaluated lazily the first time a class
> is
> > > > used in a certain way."  Can you be more specific about that certain
> > way?
> > > > Is there a certain way that would be minimally disruptive?
> > >
> > >
> > > Well, here is a non-exhaustive description of current behavior:
> > >
> > >  * If you access a class constant, only that constant is evaluated.
> > >  * If you access a static property, all initializers in the class and
> > > parent classes are evaluated.
> > >  * If you instantiate a class, all initializers are evaluated.
> > >  * Inheriting from a class or calling a static method doesn't evaluate
> > > anything.
> > >
> > > As you can see, the rules are rather ad-hoc. To the user, it's probably
> > not
> > > obvious why instantiating an object of a class would require evaluating
> > > class constants at that point. The reason is that instantiation
> requires
> > > resolved property defaults, and we happen to evaluate all initializers
> at
> > > once.
> > >
> > > The options where static properties and class constants are concerned
> > are:
> > >
> > > 1. Eagerly evaluate initializers on declaration. This is what I tried
> in
> > an
> > > earlier revision of the RFC, and I don't think that approach works. It
> > > breaks existing code and has various other unpleasant complications.
> > > 2. Precisely specify the current behavior. I don't want to do this
> > either,
> > > because the exact places where evaluation happens are something of an
> > > implementation detail. If in the future we find it convenient to
> separate
> > > evaluation of non-static properties on object instantiation from
> > evaluation
> > > of static properties and class constants (which are not strictly needed
> > at
> > > that point), I'd like to retain the liberty to make such a change.
> > > 3. Do not specify an evaluation order, beyond that evaluation happens
> at
> > > certain uses of the class. Evaluation order may change across PHP
> > versions.
> > > If your code relies on any particular order, your code is broken.
> > >
> > > Unless I'm missing a fourth option here, option 3 is the only one I
> would
> > > be willing to go for at this time.
> >
> > Thanks.  To clarify, the concern about evaluation order is only relevant
> > if you are initializing a class whose constructor has some kind of side
> > effect, right?  Writing to disk or printing or something like that.
> > Otherwise, at worst you may initialize a few more objects than you expect
> > there should be no behavioral change.
> >
> > Given that constructors that have side effects are arguably broken to
> > begin with (modulo debugging), I'd be comfortable with explicitly saying
> > that the evaluation order is undefined, and nothing is guaranteed except
> > that the value will be there when you first access it.
> >
> > In the future, if function initializers or something like that are added
> > we can revisit that question, though I would be tempted to say the same
> > thing in those cases; if you want to do some kind of DB read in a
> function
> > that is a default value for a property or a parameter, frankly odds are
> > you're already doing something wrong to begin with.  But that's a bridge
> we
> > can cross if and when we get to it.
> >
> > Would others be comfortable with that, if it allowed new-initializers for
> > static properties and class constants?
> >
>
> Honestly, I don't know.
>
> Instantiation might fail because of either a throwing constructor or
> because of a throwing autoloader.
>
> Being able to know where to put the try/catch to recover from these might
> be important when writing generic code.
>
> With the current state of the RFC, it's fine. With "undefined evaluation
> time", it might make things fragile without any way to make them resilient
> enough.
>
> We should think twice before going this way IMHO. I'm not sold yet this is
> a compromise we should make.
>

Worth noting that static prop / class constant initializers can already
throw, e.g. if you write something like "const Foo = [] + 1;". Of course,
with constructors this may become more prevalent. Even if we went with
evaluation during class declaration, the result would be pretty awkward, in
that the only way to catch such an exception would be to wrap the whole
class declaration:

try {
class X {
const Foo = [] + 1;
}
} catch (Error) {}

Regards,
Nikita

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Thu, Jun 17, 2021 at 11:53 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Wed, 16 Jun 2021 10:16:37 +0200,
> Nikita Popov  a écrit :
>
> > 1. Eagerly evaluate initializers on declaration. This is what I tried in
> an
> > earlier revision of the RFC, and I don't think that approach works. It
> > breaks existing code and has various other unpleasant complications.
> > 2. Precisely specify the current behavior. I don't want to do this
> either,
> > because the exact places where evaluation happens are something of an
> > implementation detail. If in the future we find it convenient to separate
> > evaluation of non-static properties on object instantiation from
> evaluation
> > of static properties and class constants (which are not strictly needed
> at
> > that point), I'd like to retain the liberty to make such a change.
> > 3. Do not specify an evaluation order, beyond that evaluation happens at
> > certain uses of the class. Evaluation order may change across PHP
> versions.
> > If your code relies on any particular order, your code is broken.
>
> If option 3 is considered, it means the evaluation order may change, if we
> can
> change the evaluation order, why not go for option 1? I do not understand
> which
> existing code can break with option 1 and be fine with option 3, it means
> this
> code relies on undefined behaviors, no?
>

See the example in https://externals.io/message/113347#113642. I'm not sure
how common this is, but I expect this kind of pattern does get used in PHP
code not using autoloading and declaring multiple classes perf file.

What this relies on is not so much that evaluation happens at a specific
place, but that it doesn't happen during initial class declaration, which
is exactly the assumption that would be broken by option 1.

Regards,
Nikita

Re: [PHP-DEV] [RFC] New in initializers

[Alexandru Pătrănescu]

On Thu, Jun 17, 2021 at 12:53 PM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Wed, 16 Jun 2021 10:16:37 +0200,
> Nikita Popov  a écrit :
>
> > 1. Eagerly evaluate initializers on declaration. This is what I tried in
> an
> > earlier revision of the RFC, and I don't think that approach works. It
> > breaks existing code and has various other unpleasant complications.
> > 2. Precisely specify the current behavior. I don't want to do this
> either,
> > because the exact places where evaluation happens are something of an
> > implementation detail. If in the future we find it convenient to separate
> > evaluation of non-static properties on object instantiation from
> evaluation
> > of static properties and class constants (which are not strictly needed
> at
> > that point), I'd like to retain the liberty to make such a change.
> > 3. Do not specify an evaluation order, beyond that evaluation happens at
> > certain uses of the class. Evaluation order may change across PHP
> versions.
> > If your code relies on any particular order, your code is broken.
>
> If option 3 is considered, it means the evaluation order may change, if we
> can
> change the evaluation order, why not go for option 1? I do not understand
> which
> existing code can break with option 1 and be fine with option 3, it means
> this
> code relies on undefined behaviors, no?
>
> Côme
>
> I think this message might have more details for why option 1 is not
simple to solve: https://externals.io/message/113347#113607

Re: [PHP-DEV] [RFC] New in initializers

[Côme Chilliet]

Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov  a écrit :

> 1. Eagerly evaluate initializers on declaration. This is what I tried in an
> earlier revision of the RFC, and I don't think that approach works. It
> breaks existing code and has various other unpleasant complications.
> 2. Precisely specify the current behavior. I don't want to do this either,
> because the exact places where evaluation happens are something of an
> implementation detail. If in the future we find it convenient to separate
> evaluation of non-static properties on object instantiation from evaluation
> of static properties and class constants (which are not strictly needed at
> that point), I'd like to retain the liberty to make such a change.
> 3. Do not specify an evaluation order, beyond that evaluation happens at
> certain uses of the class. Evaluation order may change across PHP versions.
> If your code relies on any particular order, your code is broken.

If option 3 is considered, it means the evaluation order may change, if we can
change the evaluation order, why not go for option 1? I do not understand which
existing code can break with option 1 and be fine with option 3, it means this
code relies on undefined behaviors, no?

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] is_literal

[Dik Takken]

On 16-06-2021 23:01, Craig Francis wrote:
>> Which leads us to the name, because "is_literal" may be, uh, too literal.
>>> So can we come up with something better?
>>
>> Throwing in another idea: is_hard_coded().
>>
> 
> 
> I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers,
> that means that it’s no longer strictly hard coded, and might get confusing.
> 

Ah, I was assuming that you were still strictly referring to integer
literals, not variables containing integers. Then indeed the name would
be confusing.

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] is_literal

[Moritz Friedrich]

> Am 16.06.2021 um 23:01 schrieb Craig Francis :
>> Throwing in another idea: is_hard_coded()
> I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers,
> that means that it’s no longer strictly hard coded, and might get confusing.

Has `is_trusted` been considered yet? That works for all data types and refers 
to the concept, namely “untrusted input”.

Regards 
Moritz
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New in initializers

[Mike Schinkel]

> On Jun 17, 2021, at 5:14 AM, Nicolas Grekas  
> wrote:
> 
> Le mer. 16 juin 2021 à 13:47, Larry Garfield  a
> écrit :
>> Would others be comfortable with that, if it allowed new-initializers for
>> static properties and class constants?
>> 
> 
> Honestly, I don't know.
> 
> Instantiation might fail because of either a throwing constructor or
> because of a throwing autoloader.
> 
> Being able to know where to put the try/catch to recover from these might
> be important when writing generic code.
> 

> With the current state of the RFC, it's fine. With "undefined evaluation
> time", it might make things fragile without any way to make them resilient
> enough.

Wouldn't the simple way to make them resilient enough be to wrap a try-catch 
block around any code that potentially throws an exception within the class 
being instantiated on initialization?

-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New in initializers

[Nicolas Grekas]

Le mer. 16 juin 2021 à 13:47, Larry Garfield  a
écrit :

> On Wed, Jun 16, 2021, at 3:16 AM, Nikita Popov wrote:
>
> > > Arguments and attributes are enough to justify this RFC on its own,
> but is
> > > there a way we can resolve the static property question?  Right now
> the RFC
> > > says "these initializers are evaluated lazily the first time a class is
> > > used in a certain way."  Can you be more specific about that certain
> way?
> > > Is there a certain way that would be minimally disruptive?
> >
> >
> > Well, here is a non-exhaustive description of current behavior:
> >
> >  * If you access a class constant, only that constant is evaluated.
> >  * If you access a static property, all initializers in the class and
> > parent classes are evaluated.
> >  * If you instantiate a class, all initializers are evaluated.
> >  * Inheriting from a class or calling a static method doesn't evaluate
> > anything.
> >
> > As you can see, the rules are rather ad-hoc. To the user, it's probably
> not
> > obvious why instantiating an object of a class would require evaluating
> > class constants at that point. The reason is that instantiation requires
> > resolved property defaults, and we happen to evaluate all initializers at
> > once.
> >
> > The options where static properties and class constants are concerned
> are:
> >
> > 1. Eagerly evaluate initializers on declaration. This is what I tried in
> an
> > earlier revision of the RFC, and I don't think that approach works. It
> > breaks existing code and has various other unpleasant complications.
> > 2. Precisely specify the current behavior. I don't want to do this
> either,
> > because the exact places where evaluation happens are something of an
> > implementation detail. If in the future we find it convenient to separate
> > evaluation of non-static properties on object instantiation from
> evaluation
> > of static properties and class constants (which are not strictly needed
> at
> > that point), I'd like to retain the liberty to make such a change.
> > 3. Do not specify an evaluation order, beyond that evaluation happens at
> > certain uses of the class. Evaluation order may change across PHP
> versions.
> > If your code relies on any particular order, your code is broken.
> >
> > Unless I'm missing a fourth option here, option 3 is the only one I would
> > be willing to go for at this time.
>
> Thanks.  To clarify, the concern about evaluation order is only relevant
> if you are initializing a class whose constructor has some kind of side
> effect, right?  Writing to disk or printing or something like that.
> Otherwise, at worst you may initialize a few more objects than you expect
> there should be no behavioral change.
>
> Given that constructors that have side effects are arguably broken to
> begin with (modulo debugging), I'd be comfortable with explicitly saying
> that the evaluation order is undefined, and nothing is guaranteed except
> that the value will be there when you first access it.
>
> In the future, if function initializers or something like that are added
> we can revisit that question, though I would be tempted to say the same
> thing in those cases; if you want to do some kind of DB read in a function
> that is a default value for a property or a parameter, frankly odds are
> you're already doing something wrong to begin with.  But that's a bridge we
> can cross if and when we get to it.
>
> Would others be comfortable with that, if it allowed new-initializers for
> static properties and class constants?
>

Honestly, I don't know.

Instantiation might fail because of either a throwing constructor or
because of a throwing autoloader.

Being able to know where to put the try/catch to recover from these might
be important when writing generic code.

With the current state of the RFC, it's fine. With "undefined evaluation
time", it might make things fragile without any way to make them resilient
enough.

We should think twice before going this way IMHO. I'm not sold yet this is
a compromise we should make.

Nicolas

Re: [PHP-DEV] [RFC] New in initializers

[Alexandru Pătrănescu]

On Wed, Jun 16, 2021 at 11:17 AM Nikita Popov  wrote:

>
>
> The options where static properties and class constants are concerned are:
>
> 1. Eagerly evaluate initializers on declaration. This is what I tried in an
> earlier revision of the RFC, and I don't think that approach works. It
> breaks existing code and has various other unpleasant complications.
> 2. Precisely specify the current behavior. I don't want to do this either,
> because the exact places where evaluation happens are something of an
> implementation detail. If in the future we find it convenient to separate
> evaluation of non-static properties on object instantiation from evaluation
> of static properties and class constants (which are not strictly needed at
> that point), I'd like to retain the liberty to make such a change.
> 3. Do not specify an evaluation order, beyond that evaluation happens at
> certain uses of the class. Evaluation order may change across PHP versions.
> If your code relies on any particular order, your code is broken.
>
> Unless I'm missing a fourth option here, option 3 is the only one I would
> be willing to go for at this time.
>

I think I was one of the people that came up on the mailing list with the
idea that it would be good to have the order of evaluating the initializers
clarified in the specifications.
Little did I know at that time how constants are "evaluated" until now.

I watched the topic and comments you added few months ago on the PR while
you were doing the implementation and got into trouble with preloading that
really can't work nicely with eager initialization.
I didn't say anything at that point but my ideas went towards option 3 as
well, specifying that the evaluation order is not well determined and can
change in the future so I agree with others here.

It's not the first time this happens in PHP (https://3v4l.org/fQhgB) and I
think we will be fine with it.

Alex

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Wed, 16 Jun 2021 11:16:28 -0500,
"Larry Garfield"  a écrit :

> Hi folks.  The vote for the Partial Function Application RFC is now open, and
> will run until 30 June.
> 
> https://wiki.php.net/rfc/partial_function_application

From the RFC:

> The ? character was chosen for the placeholder largely because it was
> unambiguous and easy to implement. Prior, similar RFCs (such as the original
> Pipe Operator proposal from several years ago) used the $$ (lovingly called
> T_BLING) sigil instead. So far no compelling argument has been provided for
> changing the character, so the RFC is sticking with ?. 

The main argument for $$ is to be able to have partial methods with $$->, this
 should be stated in this paragraph.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Wed, 16 Jun 2021 11:16:28 -0500,
"Larry Garfield"  a écrit :

> Hi folks.  The vote for the Partial Function Application RFC is now open, and
> will run until 30 June.
> 
> https://wiki.php.net/rfc/partial_function_application

I do not understand how this ... placeholder works, it feels inconsistent.

From the examples:

> $c = stuff(...);
> $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)
>   => stuff($i, $s, $f, $p, $m);

> $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);

Why is there an additional variadic parameter in this one?

If I remove the 5:
> $c = stuff(1, 'hi', 3.4, $point, ...);
I get this right?:
> $c = fn(int $m = 0) => stuff(1, 'hi', 3.4, $point, $m);

Why the ... does not produce 0 parameters when there are none left?

Also, in the second set of examples:
> function things(int $i, float $f, Point ...$points) { ... }
 
> // Ex 13
> $c = things(...);
> $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);
 
> // Ex 14
> $c = things(1, 3.14, ...);
> $c = fn(...$args) => things(...[1, 3.14, ...$args]);

What happens to the typing of the variadic parameter here? Why is it removed?

It would feel natural that the ... means "copy the rest of the parameters from
 signature". Here it seems it sometimes mean that, and sometimes mean "accept an
 additional variadic parameter and pass it along".

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.21RC1 is available for testing

[Derick Rethans]

PHP 7.4.21RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.21RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system at
.

Hash values and PGP signatures can be found below or at
.

7.4.21 should be expected in 2 weeks, i.e. on July 1st, 2021.

Thank you, and happy testing!

Regards,
Derick Rethans


php-7.4.21RC1.tar.gz
SHA256 hash: 6d6813294ebd241f077dd6bdfa234e3ebe64990aaa693c6eecaa550be34b95f8
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDI9nkACgkQkQ3rRvU+
oxJ0/hAAt848VjiZwyLsBITfFhQA+UQEJ6Sg8jdCY2RtemkLVB1+7x4irnmcrpUB
NdOkuIhNEwiZN3LSXxP65DPyc+ePAoNpijOyonbL6aaHwHic4+sjVZy4IvSHtXNJ
X7r41/P1EtZWm2wPNK8eorjfMLRPIh3fK2mTgbq4d501X3rQ2PcCCAHJl+ZUlSgc
X6WXBDDyF0cBBfPPlULH4i32dynNB5q/JTLd2OQl1di8XnSwnudbCaL436sqBdkC
KaP0srHduo/hMlXq+JnILA6Y8z+isJQATjtRZudg2vex03mTsCEsV+lDu8IEtVGj
zUtVapRhb0EX7aBZlgLyUl7p58iwZdjl8dwzs03zaEtZHaS2x8EcpMtFwfflIyqY
3dyfCWkCAjrQmTHiCxdZ7xjA1+ijZ4bMynsFwtkR56cCTpiNTFQZWoK1R/ijgT0Y
oMOzPuNDC1MG1E0ryYoBPjQCHEPUrNwy0asmVQDTd1C8voyAfwGTVU/w9Xa0vwqd
nYrR9PsLsjdPPm7XJz2FotnDL74CWgrgC0P1Jyi/nTpzH16u7ntfbumrP1VRlCS4
1MuN5Zs2jUmyxbuc2I4o5M4KlYZCuzjhCfb5759eWKOFwVhoGcw/9A6hhnJRYmN4
oMJqOBOdvjtvlRJxlXZoCijqo1efUrIw5ogd53PaFYee+F5PWAU=
=mn+F
-END PGP SIGNATURE-

php-7.4.21RC1.tar.bz2
SHA256 hash: 854ea5bedada755501b80b12505c2f84600c54ee1fee8405df6baff76d863f2f
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDI9n0ACgkQkQ3rRvU+
oxIQiBAAmUdTleQcunzhrVFWfaUDuNL1UdctCOo8my6YU8VMFxTnyuf9agnmPmgs
3MDRytEYSg5WeUxLKc/44w1cjP5DyP3AggodJhTX4JhZPMBhBzah2ais6bvDSZw3
QYXIct444BNY7jEMnL6XS/YspM2PtyyqRpEVTJTz0Vl03u4Hp5IGDWx8LGikmYO/
D6w5zlOvyVUNZAo3ffbj1WMnu1hZFqonnA6+NqIuJkoyudAalExvsJKx2GeR+4yl
T4Hr08LCwwH/HgLU795fzf9tD7rUkH7rtE+Pp03SzYGQ4LZZ35G7b2H7j5rzuoLw
M9W+7Xzg7/qTbVqU0cvDwVNcx9KWbkQU3GPzWF7Ta2H4NJxvQ932qE9LNqU5ZMp1
CgNmmL65DJRCKIkM3fC7VsezVPJDAonNbh5niG4iCUeHj69/TNaHem6IO128ZC/d
4q0bR0ucq7eFurp8Fu9kLEOSMozZrsehCTWbhpWdOZn3ZhEykUH4IxxDp25dCaPM
J2bz1jBZF2DmyAMNh6HJKTvHuj6HttfPOvPaBfCOeBced+qX+z7MZAo/whcN8NUu
/2Cfe8eSJd56ScyACohQ6uetIFeow4N4ivGSVlv8pZCks6kwhsWiVbX01OZiq1d8
JKRtRXbItMFdeSQ/dyG/XG65RD+EspBG7azCmt5Uj9+4bpZR6a0=
=Rilv
-END PGP SIGNATURE-

php-7.4.21RC1.tar.xz
SHA256 hash: 42130f96ca0993ffb18d5f50d97cd2e3be6e9464b7c012667d80b80dea65eb26
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmDI9n0ACgkQkQ3rRvU+
oxI45RAAzZw58E8w5+X+I4qvkeBLQz8Vykm8+hPvt9PldqH8GmvGeLV0iL4jh4gT
YaX3+KOxcul9ce4re8E63aSua6wuvMwZ9YXbSIRRbWywO++Q08yw9AoApZXVV2rI
nTXixeyDx+5vpYKejnqFYSJzzvsX6r8TQZSD1O0h+LgiJa8HpEDvqk+RbGBsPB1W
I18O7DQXzyd3YfUc5ja7+5+1CQ0uyIXHBSVZnbsVT4QhOTAxkZVpkamoEZm5qRSZ
CEfdaOyIcgKdgWnAG+UQMoRElgwe/wKmfgJCYE0PaZQpPN/hq+u40r6nfEMq6KfJ
W1dUDlxleEZ58TdX9vlqZuDnqmcWFiUFla+ilbCqI+uAv8fhLEfm+aPe/HPp28zA
OCSo4iVjEomlECsxbFUHEAiPSKC0rE3zYBzvysSTD7Hzxe09yk+Z30EfDHGXrwOX
6phuWR0M21BcvK5H/Ii80y9yWzSAe4G7TjQQiTpRiojI+RbvaRavAXVWH4wOayFT
UFedsBz2sOrGGtonsJAwK4Q8XvBKofDO0DpwodwM3jteQlv60egisNBs9FAh5fD9
F0tEyVfLx78xP2w1kiRHoar6K6aKk6hfTYVNNbsTfKGNIDeySPN3W+GTLAZV9AJN
M15wuiR99IGOU1XVObH5Dm8Jbu4y3yN6+MldL1ykxCU2OJsi+lE=
=ejnH
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New in initializers

[Mike Schinkel]

> On Jun 16, 2021, at 7:47 AM, Larry Garfield  wrote:
> 
> On Wed, Jun 16, 2021, at 3:16 AM, Nikita Popov wrote:
> 
> Given that constructors that have side effects are arguably broken to begin 
> with (modulo debugging), I'd be comfortable with explicitly saying that the 
> evaluation order is undefined, and nothing is guaranteed except that the 
> value will be there when you first access it.

A big thumbs up from me.  

I cannot think of a scenario in userland where evaluation order prior to access 
would matter and not be able to be worked around.

-Mike