Re: [PHP-DEV] print with newline

[Sara Golemon]

On Sat, Mar 2, 2019 at 10:26 PM Steven Penny  wrote:

> On Sun, 03 Mar 2019 03:36:50, Sara Golemon wrote:
> > function println(string $x): void {
> > echo $x, PHP_EOL;
> > }
> >
> > I hereby grant a public domain license to the above code and wish you
> > godspeed bundling it into a composer package to be enjoyed by users of
> > every active version of PHP.
>
> my request was not "how to print a newline with PHP". the request is for
> PHP to
> implement a builtin method that prints a newline *by default*. currently no
> method exists that i know of.
>
> My apologies, I was obviously not being clear.
What I should have said is that your request is bad and you should feel bad.

Hope that clears things up!

-Sara

Re: [PHP-DEV] print with newline

[Sara Golemon]

On Sun, Mar 3, 2019 at 6:45 PM Stanislav Malyshev 
wrote:

> This is not Twitter and not any
> other forum where such things are welcome.
>

I want to apologize for my behavior on this thread. I know you're directing
your message at another party, but I was churlish and instigative. I really
should have exercised more patience and decorum, and for that I'm sorry.

-Sara

Re: [PHP-DEV] RFC Draft: Comprehensions

[Sara Golemon]

On Sun, Mar 10, 2019 at 4:45 PM Larry Garfield 
wrote:

> Sara Golemon has written a preliminary patch that is partially complete
> (see the RFC link for details, it's impressively simple), but unfortunately
> doesn't have the bandwidth to complete it at this time.  I am therefore
> looking for collaborators with more knowledge of internals than I (which is
> almost everyone) to help finish it up.
>
> Just want to clarify; The proof-of-concept I made for Larry is *just* a
proof of concept to illustrate one potential syntax.  The actual
implementation is a dumpster fire that was hastily assembled between
conference sessions.  Please ignore the mechanics of how it was put
together and focus on the intended syntax and resulting behavior.

-Sara

Re: [PHP-DEV] Re: PHP 7.4 Release Manager Selection

[Sara Golemon]

On Mon, Mar 18, 2019 at 7:08 AM Christoph M. Becker 
wrote:

> Great!  Since we only have two volunteers, there's no need for a vote.
>
> Ladies and gentlemen, I give you your PHP 7.4 Release Managers:
>
>   Peter Kokot and Derick Rethans
>
> Yay! And on that topic, did we come to a consensus on whether or not 7.4
was going to have an extended support cycle the way 5.6 did? If so, how
long was it?

-Sara

Re: [PHP-DEV] Re: PHP 7.4 Release Manager Selection

[Sara Golemon]

On Tue, Mar 19, 2019 at 9:49 AM Remi Collet  wrote:
> >> Yay! And on that topic, did we come to a consensus on whether or not
7.4
> > was going to have an extended support cycle the way 5.6 did? If so, how
> > long was it?
>
> 5.6 support, as latest 5.x, was extended by 1 year
>
> I think it make sense to do the same for latest 7.x
> (so 2 years of security instead of 1)
>
I agree and think it's worth putting such into the release process as
standard practice.

-Sara

[PHP-DEV] PHP 7.2.17RC1 ready for testing

[Sara Golemon]

Hi,

PHP 7.2.17 RC1 was just released and can be downloaded from:

https://downloads.php.net/~pollita

Or using the git tag: php-7.2.17RC1

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
7.2.17 should be expected in 2 weeks on April 4th, 2019.

Hash Values and GPG signatures can be found below and at:
https://gist.github.com/sgolemon/27c2326bcff267703c1649c7d660361b


Thank you, and happy testing!

Regards,
Sara Golemon & Remi Collet

php-7.2.17RC1.tar.gz
SHA256 hash:
dcd1dfd5c12c667917f06bc16eb17544c647b57092af0d3a7a461e4cac136b1a
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJckllCEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJSuQ//
S8dj8/Pw/eNXkqCTAHabmC184g2XQUQf4vedc8Xzdw9qgeLNb2YZBOYxEeHLKooB
UNNm45D5AsN86H38xjZafQoQb5BbAcJazF5GhYpnLvAZOQ1LncFwh36zQDI20Qj8
fDzOcy05JgcKE43Df54octowCCveJzF36Ve+Z6IE4/2O3weCc68yvfnKMKU31PNF
Ny5FfT6E7etwdm35q2VITWPF3mPdLuGONh9EkxMMJ6y37QTHfLorGxL7Ql1eRQ48
Pr5hfhBGmPg9FQgMVvEk+hKeTBekb+ENu62Y0zSiROMZ4MHcIiU9ueyqv0Tbs2O3
I7pnZQXAdazFbB/T5xBNR4CIYbOOZoQJ4/mnC4Fw+4qlNCFyLj0gg3dv0jDASsGU
qNE3nJoq8yiFn8Pouph2Cjsd3crSIxoVX95CId2V91VUvY0I8HwmKiTY8B6VG3Ap
xPZ1CSUp85uF56YBGx+bFP8qMmqj5ui1Dd8kWIGP1fB4UVJgczwFAedjgHni5D+8
g4nuOzu8PFQvvgFxFMkaEUe0Ra4I6UROuWHT9+mwBhZM+rOcpAMpcZX1IQn+1mdZ
zTLnRkWt69AqLwSrGWLZ5+GkMMCVaoZhTLJe3IDFzDBe2TaA5hrqyasgo/s14VNa
4lXfz1hl1QBfy1WWFMKCGtPZoEybmXKxGc2FQdrOtyY=
=5fLv
-END PGP SIGNATURE-

php-7.2.17RC1.tar.bz2
SHA256 hash:
2e2ed5993df303b4c9e43610fe9ef76f42d8fe6a3182a2f312ec238709109fbc
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJckllGEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXKSQw//
QFtOGub9xGXjq56EP5p74UrQy3uNHz907fhzsKSF6yYtRjFhzOQduNKAsyLK8k5G
om1eBF2lIp2Mi7yrOX4+XIFs66Bk3QRZ/j2jwKiVWh4Ic8I0IXU29XA7NUvgQLVA
e3EM7yV4Tbry5uJPuOk0Kb7LkLvAynsB5B0W+BvUU8eciexmjTMLxLrdpu72jdht
tO6tkrJqpzVKbMw1eU+A0hwEGxUKuaGfCbOvTIlIXJ7vPyZgN1o/nJWrUnG0apEt
nfI7DStlgWtwKbMB79GaUkCAboVQd1Bi8Ae2NHSbgh7WwF3WKMxZwMGJJ04dX8AS
wwYXm+hzZi2GK25WZRJ4oq0F/VdfynhSp3zOabr27vzi4r+R6K3pBsI7Qyd1fQbS
0uFyoiuIiWXBdTrCOg0ZrXFGZSYCR7R65Sq4BvVMBgvcdSgeK0SCKWe90NGiXXBm
+3eW2U8s72kcjLAUXWqGdbnE98qOc3zf8KKz1Xn6BZUlVPtpX/bW5ocgOiaT9ALF
8iOv0Y47pSFDu1GJ7gMjbdaOPDV8zT7vn06hudUTle8aZeWM1R4iEhpVlegsCVw4
JArBEpB1/BaOk9G2o6voiMpXo57goJ40QqRrEhyHM5FPJMkrNLb9kATFHx+z+zLu
qHLMY6MNSBQvVQjHXQiWgnpdVeWyo0zJAYciarvGM/Y=
=5+qA
-END PGP SIGNATURE-

php-7.2.17RC1.tar.xz
SHA256 hash:
359ca48d5ea87498ce91e5ddf8eca4a537d715dbef0d1dd1ce1028fc5d09d10b
PGP signature:
-BEGIN PGP SIGNATURE-
iQItBAABCAAXBQJckllGEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJSpQ/+
KGw9AAr+RLkKYCvzF25l8KYxhBTwWt0Djrl+UXxAY2o9Fk5IGsVsG7fGRMgg61oJ
oapLfHU73h0Fp/t35O8tiNU5NfinlogJH0pictAF3wOsLyi0qhCPglcn6DLL4IGA
Dt7k7k7ckpcRIBvj2/SxrQc91akg1r0Oj9yOjP1N7xCQ3No5/MchBFGD75EH/Ays
a2fg8NYekqPcnTYneXAatvIkHxDOEJ/p4gps2nB464zpxbVOChBO4ZI6t5Ihu6h5
4muZBVLM44VhGK2FePfkEV/VZ2hquniC1GEBEwWdgdY8tHQKTAho30BidNXnEdwo
8JZ6JakTyygVlOCaUzkDv+lqCOR34/qLEC5vCsHCLQR67LLCywg6itAzM9sUTp/4
Ku4IpKkPI2BXFf+81OBX8mMqWOdBvSfN49Lmg1ZbWzBtL80I2r0o9q2BC1S7N67G
G+Sct6ZX98jVnNWkhvUNw2P2sCYlE+Lps+gNoADIiAsFnEMaCCwk7JtjFRLwpoib
mLDjbk4/D9rDXDECDp+ZH3fgXHGA5rfkBm4DdXMyX9LjD7ic2TeUzsSbfJaJO9Zk
R1ZdO2dGBVZoEUnVNkXC21OPIIU2CbfbbYI/XwBbelauyo+2EQTLtfFhX2bU0D4X
z6IFM8U9ljnEU/7CC/2Nv22J+LbYIPuInjkYUiWD6S0=
=YdcD
-END PGP SIGNATURE-

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

[Sara Golemon]

On Tue, Mar 12, 2019 at 11:57 AM Stanislav Malyshev 
wrote:
> > I'm currently going through the PHP doc to remove mentions of PHP 4
> > and stumbled upon the short_open_tag ini directive [1] which only
affects
> > the availability of ` > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether?
>
> Why? What would it improve for people that are using it? For people that
> aren't, it obviously won't change anything. So what would be the
> motivation for this change?
>
I'm with Stas (and some others in disconnected sub-threads because email is
hard).  This RFC needs a better "why this is important" section.  Yeah, I
get that it being an option makes writing portable code harder, I get that
the XML open tag is something that can be tripped on, but why is removing
it a sufficiently better solution to the "problem"?

As we stand now, code using short open tags works when those tags are
enabled.  As we'd stand in the future, that code would not work.  That
level of BC break requires a strong justification.

-Sara

[PHP-DEV] Argon2 default time cost

[Sara Golemon]

In sitting down to expose libsodium's argon2i password hashing function via
password_hash(), I discovered two things.

The first is that it doesn't seem to support Argon2id for password storage
the way we use it in password_hash().  Bummer, but that's a conversation to
have with Frank, and there's nothing we can do about it for the foreseeable
future.

The second is that crypto_pwhash_str() and crypto_pwhash_str_verify()
reject any attempt to use a "time_cost" value less than three.  Wanna guess
what our default time_cost value is?  That's right, it's two.

So that's a long winded way of asking, does anyone see an issue with upping
the default time cost for argon2 to a higher number? (e.g. "3")  This will
ensure that the following actually works as expected and doesn't give users
confusing result and more importantly, allows us to use sodium to back
argon hashing interchangeably with the more lenient libargon.

$hash = password_hash("Foo", PASSWORD_ARGON2I);
var_dump(sodium_crypto_pwhash_str_verify($hash, "Foo")); // currently
FALSE, due to t < 3.

The only negative impact is that password hashing becomes a slightly more
expensive task.  Where "slightly" means 3ms instead of 2ms on my Linux VM
running on my 2 core Mac laptop.

-Sara

[PHP-DEV] Re: PHP 8 Preview Releases

[Sara Golemon]

On Fri, Mar 29, 2019 at 7:40 AM Joe Watkins  wrote:
> Since we now have a result for JIT and we know it will be included
> in PHP 8, I think it's time to visit the idea brought up in discussion
> to have preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going
> to be useful - it's tempting to say let's track PHP-7.4 releases,
> possibly with a bi-monthly interval, but I'm not sure if that may
> be too soon, or too slow, or too fast.
>
IMO, preview releases should (for the time being) be largely driven by the
progress of branch.  And by branch, let's be honest, I really mean the
JIT.  So for the rest of 2019, this essentially (but not completely) means
"When Dmitry wants something taken for a spin".  Maybe he rolls those, I
don't mind rolling them for him if he's not inclined to do it.

Coming into 2020, I think we should have monthly previews beginning one
month after 7.4.0 GA until we reach the normal alpha period. (Preceding
sentence is entirely provisional and subject to review as that time
approaches)

-Sara

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Sara Golemon]

On Wed, Apr 3, 2019 at 4:52 AM Benjamin Morel 
wrote:

> I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
> the smallest **positive** number representable. Is this expected?
>
> This is unlike PHP_INT_MIN, which is the absolute smallest representable
> integer, and as such is negative:
>
> echo PHP_INT_MIN; // -9223372036854775808
> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
>
> If it is intended, maybe the doc
>  should be clear
> about this, at the moment it is just:
>
> Smallest representable floating point number.
>
>
> Which is confusing IMO.
>
> Perhaps confusing, but not without precedent.  See the C++ definitions for
::min() and ::lowest() on
https://en.cppreference.com/w/cpp/types/numeric_limits.

std::numeric_limits::min() is a positive value very near zero.
std::numeric::limits::lowest() is a very large negative value.

-Sara

Re: [PHP-DEV] Question about adding !function_identifier

[Sara Golemon]

On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe  wrote:

> I have a quick question before any formal proposal; would it be complex to
> add an exclamation mark indicatorin front a function identifier to indicate
> that function throws; like the nullable question mark for types however
>  without any runtime check something like a pure syntax indicator to make
> the code clearer?
>
> If you're suggesting something with no runtime validation, then why not
simply use docblock annotations?  They're widely supported and understood
already.

Basically, what will having that syntax give you that not having it won't?

-Sara

[PHP-DEV] PHP 7.2.17 Released

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.17. This is a security release which also contains several minor bug
fixes.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.17 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_2_17.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.17

Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet

Signatures and hashes may be found below and at:
https://gist.github.com/sgolemon/cf4777b29231cd766626ac13ea8eadb2

php-7.2.17.tar.gz
SHA256 hash:
e1c6c2553cdb7edbfa65b89e259690ed01b31b12d57349c90b6ed00a410f62b5
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49UEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJz2hAA
2zaMlRyK6f1oyFsLFbzzJqPcv1jHpIgs20ryIggtMuBBTw0BCX0jnXU1LM5JBE8B
kG1C1goPDOkF7GmmD1Heep2TaIPm+t33qWRT1XgbK83PK6aiAoIrmSovou6dYd2W
gDB7uExhWYzm58HlYdmDnaGM9Lr8ebnC8UWYztCXQYFR/8RaLwgo2D/JLONph9Cu
+knxBojxBjQdsBgkTjo5c5c4Dln1+G7xtAURFGj58eo0SnC3sxVNspX4G38Ipz31
ZGpfr+46VWBRiWxMqZB885aUUTj1pnY2JnmdAVAmNSuNJT6gaw92CrAR0idDfKVW
d0u+lRDCxVLWCtOmJtCpFyHRj2Ow6R81ukSREGUDtyROx+iCDorueE1/CqY0l1Cb
JGQnxgaI1S+BZlXSlBt5ZscA/neqseIf6MrTaenX3rIGQXQaZtQuc8HyvBkLxIE7
AcnK5ZKZJvayKAeEg35U6HWKeKMXrx9GNgSbDQ0UHmpvhTCdhA77SXqH4UgMthy9
LI6UcC7dNVgn+5yFVltLq+V42tDRcISf4X6x3y5cxYFbaiI7CUHx4q0TGjLGHEDT
PbRRc6KGKyjmJ86NEkYxgNdYpbzIsck5HZM6mbcmrNexONimXAI8oIUxWx9tk3hq
M422JDZpmX7Tt5Z+TYMTjyAxFY7bm9Y/v+UuvNa2h7g=
=dAoz
-END PGP SIGNATURE-

php-7.2.17.tar.bz2
SHA256 hash:
91a811ab6f6d7acb312159cf6b0a3cffe968676fdebf042e9253245cc6094f75
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49XEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIk7A/9
FwSjRk/MBYppp8fdT00nr7sraALt24OH3NR4EK4zUxlRv/FaJ6OlM8Pt7lXUQxT5
gn1ZbxxQXcNY6+ngy1nzaCXO1pLlCa4vYb2Q7r7fhBs/BghFGhnGAsh04nVCmOT1
sx3UlhwSnEqPTDwKKUyyCje7A+7nKDe8Oxdeq4hqBw1eReri0OiwP6xL+zIuIIfg
L/W6ffHdC5h6BOxOQOgWxFKgtjw1W5Iy93zb0B4hjkSt+0IGih24mMEjlLVjTgnO
Eps5HJOsBEFIkIpZNAam/msuWbXsaKEpC4UVHkLM5hSA/rad4NxC8rfuxMtIOcCM
9TQ0LqLq73r3C6atumS6sDj3rpKlwfEHlSVzJBUQoQtibSbd1C3HyU3RsDz4AVPr
eAtQNi1mD60o6wucGJT0MpStQlaDgPoZ4JvKpvV1lDpuVdJkxbZsKPHFD/yyC02n
ZxXnuAJRJyH5D8iqjyhWVqvFiF37vpREam96loa2S2b3uujoor0nmFUQKWWkaJ6h
PAA7xi4f5WKp5VknxtFBGj7XQS3BS8t5RasXXe/1BYybr+mIpG4IzrA2mk5WF7JV
aQV9zZkzOOkdwhBC15su+0MRWWS4z7zTYFhWw2yLjku6V/tQz3N5iJFzNUk/H0BQ
1FkC2qCeCD3CN1c0JomhMgSACv/375lJQLv6QgwgdVA=
=zNrM
-END PGP SIGNATURE-

php-7.2.17.tar.xz
SHA256 hash:
a3e5f51a9ae08813b3925bea3a4de02cd4906fcccf75646e267a213bb63bcf84
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJco49XEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJecA/+
N/76/I91j/DcevNQBCp8LLR4wDmkO0lPWW6PAOol2KIYBpKj3/fG4DyO5rGVzgYO
qKZFy5h5PrRVGuMWnhyHZ+nAy/owgSdI01YBDFSqoTrJy3PiHbtINrzsoTdG60+Q
3zaljoNbxR5+9sMviWViKBEFAdLeGqNgKkxXEe/KGXiV91Wc51VbxwswIuhVHVzy
yyd5VDMh2FuWfN5tZdZjNx9OPL6nxd5PcESdaFPBB2w2lFeRGXDT08KtM/iKKqpV
PlUoVR23PWDLkU1ZhDuaD6P78nP/q2a+zaF41hSH+YObN7g/A7YtzaQ1bmikDj5l
NFiigJfcn+7ZtXGNaidx4VTak9LcztE17TUUcLqzB9M/m5G3QaNCTfYQGQhqaWR7
4h5q7oqJDN01mejmu9L9UAiRCqFIeDUiANgAtVbdq2ZF/zrDBEVTSedFKUJjDdZi
nahacXq6EJaXIGMxEszKoxTXIxgrgL+5In91JBzT8hK0pPuCZYS1zze1lrBeLogm
OjR3Tiz1SGJ6q32VaoE/MLClBt27mdrqStDIZ3VGuVyRuucdGg33TVhqeTKSSPi8
f2XdG/+cBnkqCy/xrxRe6sXXm9vu0ugYXvPHxN2tkb+gYK7LwzfTZI5vTxjcuhXx
OPrtL3rJ2ps7aCzQzHSZIaEqpc5j6oUiDVxkMx3C1gc=
=91kj
-END PGP SIGNATURE-

Re: [PHP-DEV] Question about adding !function_identifier

[Sara Golemon]

> Quite honestly knowing that a function “throws” but not
> *what* it throws, is useless.
>
> Now if it were a proposal to add *runtime checked*
> `throws FooException, BarTypeError` or similar, I could get behind.
>
Agreed.  I use noexcept in C++ *because* it adds value.  If this proposal
were along the lines of the following (with runtime checking included),
then I could get on board:

1) function foo(): type noexcept {...}
and/or
2) function foo(): type throws(Type) {...}

I don't even expect the runtime checks would hurt the happy path much since
we already have a check for active exceptions during the function unwind,
and once we know we have an exception, we're in the sad path and an extra
millisecond to check the exception type isn't going to break the bank.

I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption. Similarly if
an exception which is not of type "Type" in (2) should do the same.  2
should (arguably) allow for union typing the way catch does.  (e.g.
 throws(Foo | Bar | Baz)

Basically, the problem with this proposal IMO is that it doesn't go nearly
far enough, and that a single character modifier is unhelpful compared to
something actually readable.

-Sara

[PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium

[Sara Golemon]

I was originally planning to just do this since I thought it'd be
non-controversial, but while implementing I discovered some gotchas, so I'm
putting it to the group for discussion.  Please give attention to the
"Backward Incompatible Changes" section.

https://wiki.php.net/rfc/sodium.argon.hash

-Sara

Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium

[Sara Golemon]

On Fri, Apr 5, 2019 at 1:25 PM G. P. B.  wrote:

> I'm all for it however isn't a 2/3 majority required for all RFCs now?
>
> Oh, indeed. Hadn't noticed that get voted on. Neat! Have updated RFC to
reflect. Thanks!

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[Sara Golemon]

On Tue, Apr 9, 2019 at 4:54 AM Nikita Popov  wrote:

> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a
> deprecation and removal of the left-associative behavior of ternaries.
> Instead, explicit parentheses should be used:
>
> https://wiki.php.net/rfc/ternary_associativity
>
> This RFC makes nested ternaries without disambiguating parentheses an error
> in PHP 8 -- we might want to consider making them right-associative
> instead, which is both useful and matches the behavior of other languages.
>
> Sorry, but I'm a "No" on this one.

It'd be swell if PHP's ternary matched other languages, but it doesn't, and
we have 20 years of code in the wild which has accepted that fact and moved
on.  I don't see the benefit in breaking that code. Advise the use of
parentheses and move on.

-Sara

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[Sara Golemon]

On Tue, Apr 23, 2019 at 3:56 AM Nikita Popov  wrote:

> Can't say I understand your position here. Don't want to change the
> ternary from left-associative to right-associative? I can understand that:
> Silent behavior changes are always problematic. This is not what the RFC
> proposes though.
>
> Did the RFC change since introduction? I may have been looking at a stale
load of the page (opened it up awhile ago and only just got around to
responding).

As for what it says atm, I still think it goes too far.  the warning in 7.4
I can support, but I'm not a fan of breaking existing code on a feature
that's this old. Ratchet up the warning in 8.0 if you'd like, but error is
further than I'm willing to go on this one.


> 20 years of code in the wild has not "accepted that fact and moved on". If
> a left-associative ternary is used, it is almost certainly a bug. If people
> use this structure by accident (because it is familiar from other
> programming languages), I'd like them to get an error instead of having to
> figure out why their obviously correct code is not working or, in the worse
> case, just leave behind buggy code.
>
> I'm on dismal wifi at the moment, else I'd do some searches, but do you
have any examples of code in the wild subject to this bug?
I agree it's a lousy state, but it's not emergent.

-Sara

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[Sara Golemon]

On Wed, Apr 24, 2019 at 1:56 PM M. W. Moe  wrote:

> until this RCF does not happen; I would say nothing interesting will ever
> happen.
>
> Please, Reality TV is less hyperbolic than that.
JIT isn't interesting?
Typed Properties isn't interesting?
FFI isn't interesting?
 Preload isn't interesting?

Pack it up, folks!  Nothing we're doing here is interesting or ever will
be, because the associativity of the ternary operator is wrong.

-Sara

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

[Sara Golemon]

On Wed, Apr 24, 2019 at 6:48 PM Christoph M. Becker 
wrote:

> On 24.04.2019 at 19:25, Sara Golemon wrote:
>
> > On Tue, Apr 23, 2019 at 3:56 AM Nikita Popov 
> wrote:
> >
> >> 20 years of code in the wild has not "accepted that fact and moved on".
> If
> >> a left-associative ternary is used, it is almost certainly a bug. If
> people
> >> use this structure by accident (because it is familiar from other
> >> programming languages), I'd like them to get an error instead of having
> to
> >> figure out why their obviously correct code is not working or, in the
> worse
> >> case, just leave behind buggy code.
> >
> > I'm on dismal wifi at the moment, else I'd do some searches, but do you
> > have any examples of code in the wild subject to this bug?
> > I agree it's a lousy state, but it's not emergent.
>
> See <https://externals.io/message/105345#105389>.
>
>  Okay, so the most compelling part for me in this analysis is the fact
that Symfony and ZF have issues.  I can shrug off a lot of questionable PHP
coders, but i have to acknowledge major frameworks stumbling on this gotcha.

Convinced.
+1

-Sara

Re: [PHP-DEV] Don't silence chr function arguments error

[Sara Golemon]

On Sun, Apr 28, 2019 at 6:05 PM Gabriel Caruso 
wrote:

> Currently, if you pass an argument that is not an integer, it will simply
> return an empty string: https://3v4l.org/FF2nA.


Not entirely accurate. It outputs a one-character string (the null byte).


> In case you pass more than
> 1 argument, it will complain about "Wrong number of arguments":
> https://3v4l.org/Yrr43.
>
>


> The proposal of https://github.com/php/php-src/pull/4080 is to relly these
> checks to ZPP, making the first argument mandatory to an integer, and make
> the error message for extra arguments consistent with the rest of the core
> functions, e.g. "Warning: chr() expects parameter 1 to be int, string
> given".
>
> I'm actually perfectly in favor of raising a proper warning here.  I
noticed the odd behavior when I was porting this function to HHVM and IIRC
I raised a discussion about it and the bottom line was "Let's not do this
because X", and I couldn't possibly tell you what X was. :(
The thread is out there somewhere though.


> The idea is to merge in PHP-7.4, but if there's a consensus that this
> should go into PHP 8 only, so it is :)
>
> Technically a BC break, so 8.0 would be the preferred branch IMO.

-Sara

Re: [PHP-DEV] Don't silence chr function arguments error

[Sara Golemon]

On Mon, Apr 29, 2019 at 2:37 AM Nikita Popov  wrote:

> > The idea is to merge in PHP-7.4, but if there's a consensus that this
>> > should go into PHP 8 only, so it is :)
>> >
>> > Technically a BC break, so 8.0 would be the preferred branch IMO.
>>
>
> As this would be a TypeError on 8.0, I think it might make sense to
> introduce it in 7.4 where this is still a warning (and should keep the
> current "\0" return value in that case -- just make it throw a warning).
>
> Sounds good to me.

Re: [PHP-DEV] Remove $age parameter of curl_version()

[Sara Golemon]

On Wed, May 1, 2019 at 12:18 PM Christoph M. Becker 
wrote:

>
> curl_version()[1] (of ext/curl) makes curl_version_info()[2] (of
> libcurl) available to PHP userland.  The latter requires to pass an age
> argument which usually is CURLVERSION_NOW, so that the information
> returned by the runtime matches the declarations used during compile
> time.  For C programs it is simply necessary to pass this information,
> and it might make sense to pass something else than CURLVERSION_NOW, but
> the PHP wrapper assumes that the return value of curl_version_info()
> matches the compile time declarations anyway, so passing anything else
> might give bad results.
>
> Wow... yeah. That's an example of being far too idiomatic with the
bindings. I didn't even know we accepted that arg.  Kill it with fire.

-Sara

[PHP-DEV] zend_atol() and zend_atoi()

[Sara Golemon]

I fell down a WTF hole today that led me to zend_atol().
The end result is the PR which I'd like to present for discussion (I'll add
tests before I push anything, though it might necessitate a vote).
https://github.com/php/php-src/pull/4132

The issue is explained in the commit message, but I'll copy here:

zend_ato[il] don't just do number parsing.
They also check for a 'K', 'M', or 'G' at the end of the string,
and multiply the parsed value out accordingly.

Unfortunately, they ignore any other non-numerics between the
numeric component and the last character in the string.
This means that numbers such as the following are both valid
and non-intuitive in their final output.

   - "123KMG" is interpreted as "123G" -> 132070244352
   - "123G " is interpreted as "123 " -> 123
   - "123GB" is interpreted as "123B" -> 123
   - "123 I like tacos." is also interpreted as "123." -> 123

This diff primarily adds warnings for these cases when the output
would be a potentially unexpected, and unhelpful value.

Additionally, several places in php-src use these functions
despite not actually wanting their KMG behavior such as
session.upload_progress.freq which will happily parse "1 banana"
as a valid value.

For these settings, I've switched them to ZEND_STRTOL which preserves
their existing /intended/ behavior.

   - It won't respect KMG suffixes, but they never really wanted that logic
   anyway.
   - It will ignore non-numeric suffixes so as to not introduce new
   failures.

We should probably reexamine that second bullet point separately.

Lastly, with these changes, zend_atoi() is no longer used in php-src,
but I left it as a valid API for 3rd party extensions.
Note that I did make it a proxy to zend_atol() since deferring the
truncation till the end is effectively the same as truncation during
multiplication, but this avoid code duplication.

I think we should consider removing zend_atoi() entirely (perhaps in 8.0?)
and rename zend_atol() to something reflecting it's KMG specific behavior.

-Sara

[PHP-DEV] 7.2.19RC1 Ready for testing

[Sara Golemon]

Hi,

PHP 7.2.19 RC1 was just released and can be downloaded from:

https://downloads.php.net/~pollita

Or using the git tag: php-7.2.19RC1

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
7.2.19 should be expected in 2 weeks on May 30th, 2019.

Hash Values and GPG signatures can be found below and at:
https://gist.github.com/sgolemon/b04d05669623e036904ebb2f4123a9de

Thank you, and happy testing!

Regards,
Sara Golemon & Remi Collet

php-7.2.19RC1.tar.gz
SHA256 hash:
db36b570b069ac61f17f01a4c25827fd261fc745560a6fe7b1af2ba03c4014b3
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJc21gbEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJsqw/9
E97w4mDtTklJvL+tUj69LeOy4dHVdA/DKnqhzgw41ax76pfpUmDNGUYQgk1rLdhF
zCLmhxRe8IGTrO3+l9gwt/fDsxssjwdj4Kdey4DKSrS+rda6r31oTDpRohHa7JUs
MRlISVNnbE6kzgRl9ixQPZyPgN4Ucs5GQv5ubUc547ZXzeYj/jHKI9kg0RjnNfUV
l7r6HX0zX5uvX7Tt0pp1NXbQBsynvhVL9aWsXH4yndSmOj1bs3CojWtcolxvaN6H
X7BEYQTnloZUHh/pdB0HLC5H4y8SJYNiGtGLifQwC21jOKUJKOBbwjinMYvguqo3
54CVRIiK9vpFZxHk9x12HzeSKwtbt3ayceCPNtgdNgnK6753qyPOA5OEn11J08Wu
jl9hIA/z9UeQArHYU0SGh4Pix/ig69XXWSbu28V9EyaDbX5iYMRWzRZU/aXJntt5
3DFgGh7SFVZg+65hQ5ODlXvL9YHDqxqFIpAlxyOBNXCMcF26ePU3GbW9Il/81Mtz
L3gVsZr6WSp16Du7COT6lziI/mtIqU+93KlqXRarKpbkMd1lByARsM6P8Ps37lBa
NAWwoWKXu3AD2b+HA7ui4hAp3LZdGfXmMREZS1hcBPwIXQR5Brw7qvsUqZ0pGM1L
1SAG+7sJne+37CJHqVVvJF5x5ig167UQ6ocgqN+XHjI=
=+Bxx
-END PGP SIGNATURE-

php-7.2.19RC1.tar.bz2
SHA256 hash:
504007b1a3d9712d2a175e8cd8ad19dfe0ecca63d5c4b3a1e35485f33e726f37
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJc21ggEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXLang//
UBjlxW7FxE4qvZIDsQfN2DppycnI/jgMPbEdsGfKZprEqJ8JMu2tQW2TAaimC3of
TWhXR6S+03emTCIFtt2+TqL5r+VVqpPA3tjoRt5kpkO9WJmJcIftL5nbPmDmcgep
jWj04nNeeXqLk1FTCyfk1HpnFZwGEc8zTse+hYloYMF8ozPk7rqkA6wTpzDggGFH
eNx+z6sb+b+EFnGqf9IAm13d8ofap/VEWsx5OlgEzoETaMyeFA+Zbt5wpIZ0w877
xy3CtamBnIebI/nk2Df9mdpVnbN8+jyA1IYEJg/WvTojwrxCLojLTV6QVdmKJ6tS
pduS9nAyqw9M+EQEGmxRsmepakPqfzVRz04aJweTaI+hBPF/XrznGGSEsC4fsn4J
08XCS3Aa/0RnHTAJXIuuVQhisDTaD9TWYQJczQswziswEQ4VXimp3SQfB4jpSTjr
XdxcpPSb8m6mn4B0y13F5aqNlI+inhmLte4QAERCjoR2r45KW1U1dO4xaktVVsmh
HybEjzwUU5sMarc53J6NCTMslFBORxsMaSY3X+pXyf0ZrGO161B5ipHOOyOzYTCg
aH6rtYo2a3BVr6Icn0hdbQp1tnJUA9Y/EIwfe2/EOeIjVI4JZXafcj7sOF+Gx0+t
2jdJSagGSUy9zIOYBbdwpyyke0bFTweq5III2i9vYcM=
=quI2
-END PGP SIGNATURE-

php-7.2.19RC1.tar.xz
SHA256 hash:
a63199b5fa09e39c935d3dc23ce22c66a943b68966e8db1e1800950f51234e89
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJc21ggEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXK25BAA
ybcRkSMJshDRLGmGkdP72rhTcxq7wr7BwAvGVmPBnjZC4fcYcT5N2AdgZgz/HQ4S
UQC5DUK5tSX1uYYQqptMrdBcUcepYVNNA3XO7qkLjA6daj939Fb71Uu1oFQImDg/
YK1rQ8tFZMKaUgog+GmliSthkr8IXNRDFxKmIxlYoVCFrxRL3vU2Xkm7PDTW0Mmb
8VICYuBxgJvJtYITE7IJfMV5yxE2cKTziuS6QnCG54USSscZ6O2RjtembKYJBpsm
yO6puBQrs9maD4rFwcSbmVJqfGBViUYbcR8miszH6fC0yxKE5jHRDq0a6Nzu9HAW
IfD4/YmQxHU+78aYiLzQnlU0uUmAkkQZCG5dE1OKI1IUqm0pgF6txhHSwEgCxA1J
5W7xm2HG9ZKuKoBvAsj+WpzIaXrNATlzqUbIgm8FfiNvwtbOeQHbQZP8FBgzTnpy
m1lrVJ6amX7YWLmFWYOiludheHguBVrEugIVNdfssiVDDfaKh8utnnF00o3UtEQM
HYhrAZjh6KF7veKJWFFMir34vA5QpsDe7ztt02NHtSN9IT2xYGwWC4wk0v5tP3vj
DM12dg80SY3mMXIyjBcxghvleSbke25OKSNjLrQ1fzF42SWKOMd9/3fmHccv6SVS
hFrBxeAOiRurtYbwF/zkSycw2iHHBQeJEQ4U3munRn0=
=bQDW
-END PGP SIGNATURE-

Re: [PHP-DEV] Git FAQ - "How to handle changes that should not merge upward?"

[Sara Golemon]

On Fri, May 17, 2019 at 9:56 AM Bishop Bettini  wrote:

> Our Git FAQ[1] currently says (at the bottom):
>
> > What about commits that should not be merged upwards (say, only for 5.3)?
> Should you still merge them but make it so no changes actually take place?
> Otherwise, it will the next person merging that will have to deal with the
> conflict (or worse, the changes will be merged when they shouldn't have
> been)
>
> Please, could someone supply examples as to when this scenario occurs, and
> how to handle it?
>
>
> I routinely do this for version commits on my release branch.

See:
https://github.com/php/php-src/commit/4fa32d67bf3fbea0241f0e786dbcb5517d25e1a2
Or cmb here:
https://github.com/php/php-src/commit/2d93cce03a96ee7b0265e15e2d56acd173dec682

In both cases, we do the commit on our branch, then nullify it in the first
merge, then have null merges the rest of the way down.

-Sara

Re: [PHP-DEV] Re: MODERATE spam

[Sara Golemon]

On Sat, May 18, 2019 at 5:22 AM Christoph M. Becker 
wrote:

> On 18.05.2019 at 12:06, Joe Watkins wrote:
>
> > Does anyone know what is the cause of all the spam from the announce
> > mailing list? I'm not sure who is getting it, but I'm getting a few
> emails
> > a minute sometimes, it's rather annoying ...
>
> I can confirm that the spam to this mailing list has drastically (by at
> least factor 10) increased since a week ago.
>
> > Can someone do some magic, and make it go away please ?
>
> +1
>
> Same, I set up a (probably over-broad) gmail filter to bin those, but it's
possible I'm missing some legit ones now.

-Sara

Re: [PHP-DEV] Re: MODERATE spam

[Sara Golemon]

On Sat, May 18, 2019 at 12:19 PM M. W. Moe  wrote:

> Hello,
>
> didn't get any; should ask over folks; I suspect it originates from a
> frustrated individual
> which didn't found anything else smarter  than spams to achieve his pity
> vendetta.
>

I have a spam folder full of them.  They're not "please help me" so much as
"enter this contest to win some prize".

-Sara

[PHP-DEV] PHP 7.2.19 Released

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.19. This is a security release which also contains several minor bug
fixes.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.19 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_2_19.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.19

Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet

Signatures and hashes may be found below and at:
https://gist.github.com/sgolemon/cd80f62daedc828fd6c337513781f823

php-7.2.19.tar.gz
SHA256 hash:
1cd2266a058f3224d3cba594540045542606996f026eeef96747f27f6b3d22b6
PGP signature:
-BEGIN PGP SIGNATURE-
iQIcBAABAgAGBQJc7jHwAAoJENyf+NPuWvJ/Z2YQAI+6yxXaAre/SVkIiY8qL589
3J+x5SEuJcq/DIfjJdAHXm7X8Q3WQYWfK6+2nPTRnaBVuEAGHIwt3+y97L26wGG7
MUzKZ7xZ9b74mIcVmLA5f8wVQcDlzALtlFFY3jN81bU0H1sUhNEKR94RdPS3qyVv
orKBlaIhee9NPJbm6c9LW/spiSK+s3k84eC3MyxSHfvXyh6+cgSvmFgsklNKm3e6
/pG+8enDZibCiyArt6QqS3G6SMI4CIicZflEqs+lctl2bk4dq0n7nVlAIWech899
/YT3wkEkZRw88tJcJrnlbe9zwcdiLFvr3eUwXEq/qdTJFSqg67H4j1iiYs9f9xke
uN2qa7Im0K47+G7UFwZh3556SNnSJA8ae3FUdFaVi+WbHMPInRdnJVwcG+Gf1BZa
G98O1sjRm2ifYgu+9hkmGBmHtQvMsjCSKV6VTUF+dRBXO6yTmxi1RzXCRiaWQsiD
GLUcT2MmKgVjHwoBHfLPubpqbnKyHXMMZLs3izokci/iRt7nl0blkDvNMph07TAo
p4g0CHtAGlMHt8OCEyeHEdHkp4jGG3wwBCzmVmcliq471Z04cwpA4cRJW7mKChKY
ZY7JeZT5kY8w5Ka7fSxzKZLkzYpsAJeIixiWR6TP8h3zMy+5YCLv54uKZMEVHLVy
PrwDc7t4S0Z73O/Fq+RZ
=8s8v
-END PGP SIGNATURE-

php-7.2.19.tar.bz2
SHA256 hash:
ebd0b1f375fe07ed4925acc213d2f5ef76a61bd5de174e7b666b98421a90a099
PGP signature:
-BEGIN PGP SIGNATURE-
iQIcBAABAgAGBQJc7jH0AAoJENyf+NPuWvJ/LEgP/RUe5HvFNHC3vqYhgtaiQMkP
vYTb+YSZs0b7rcR3FYlR09I0EcvEarHtes9/EsxsjYxrZ4YR9zBBzq8/+kk59I7G
h/sEWbwQEZCCHkrxuWInfrDdB7Iy+vXeMOxkvw79x0L7QW1xSIYScPyHGQMerg7o
t7HZZ8X2C9kCKmrY0PWSd2fbF/Pfp8nhb/QukEurIDgQwGAqNqGvOrXp3aIWuF9k
iGOkAqBKrrcVEZBciatRzrOL2GvtOpzMCYkt3fnlxAbzASaahu4Cu92GVk901Xmt
r9wpdeI37Vz+laDfbDwXNmbVVUdg1FUhS2hs85oogIl7oJT5BC5VF8jmY1yC7GqL
hbp9laIDzDUi0Fm5i/NHrjxBXfrqz46NfuBjMBWBOuOMVUz1AqefWV1+9lLgxVrV
R0YvVpl8vQcg5QnOX5hfsx/VLK9K/lAp9ovs3kq5EZhyXFDnHTGgZXtpdwwNHqqH
XfnJYWy9pBAv1zFlBHV2yaknxs3DmZul8CoXikHI/ul9T8GDHEGVifIV1s2qGaOt
5OK79SmmccvsYMJAVDO0xFveUdbYTFLdHMQILPjaeOtLr91QlXKguHOTpVuSa1//
H4Pej9ZvwGohc0Z4JWXIgkgARTiwQDCcfdtr2Dt695Wgj7xo82e7zsAaa6g4UFMa
tSz18/nI3AsTv+CXytQs
=5Hir
-END PGP SIGNATURE-

php-7.2.19.tar.xz
SHA256 hash:
4ffa2404a88d60e993a9fe69f829ebec3eb1e006de41b6048ce5e91bbeaa9282
PGP signature:
-BEGIN PGP SIGNATURE-
iQIcBAABAgAGBQJc7jH3AAoJENyf+NPuWvJ/xc0QAIsWKRbvGjXPJWdEAe3guF1b
PWpmPH+DRA7dq0rATizqrbOGr4dQO6m3rQ1RqutUlamXmnSvmhgLtmBJpZXR/uqH
diQSlefI+w70RfauAoVb/Wf5qipMhF6F9boqBsaMvHG6PDlw7Ii176MEKjJkR6pW
RLVq4NShYuMC0PMO9S7ys0AqaMK9vmLG2lwRASHjqPkAtzzp5T97TjiJ+171hjbM
R2zGzYIVI0Bfe+eD39kiBdq0kkrtKOhfZG/N+Emov7Hp/ejW+UqKtykfDIqmP154
hMhf1OQrDN+2zh1LDjd0bNDVTzEkJeYbhkxKG1cveoTP6Q3pyFoplv8AGGwA/j6L
AFi+/nW2/3Jx9wzhWhgwCs16gjY5LVGBsqDSQio05MHLmes6FHIg5HrcEu46ALho
DowbX+fKjv1FJaM0mVACkH0yXjIFAJZaT1cqL4LoO/Hy4tXt1/SzG7ruXpMhwt9M
5skepjIo+AWtMpXU3W6wTdcBPClEe4eGhNH+onRfosqOKpZUNKwnn5gFYnIRnPd0
hIGnbYilR2PM2RuChVJTwW1u0HELbSJLdN9bdFW6jWgGQ4K7Ks0q3UGz6EbiU7k+
bsKg9imiVxJJiMhoOy48uNG81kow2xDsDv7ZJTBYJPG5X0Tg5Ew0AGkTxIWhBv5t
FS7tUKb11JFFVSEbWanF
=zBm0
-END PGP SIGNATURE-

Re: [PHP-DEV] Disabling arginfo argument type checks for internal functions

[Sara Golemon]

On Thu, Jun 6, 2019 at 7:42 AM Nikita Popov  wrote:

> I plan to disable the checking of arginfo argument types for internal
> functions in https://github.com/php/php-src/pull/4232 (PHP 8 only). This
> is
> necessary to avoid duplicate type checks in both arginfo and zpp. Once this
> lands, PRs to add arginfo types (available through reflection) to internal
> functions will be accepted.
>
> Yay! We can finally get decent reflection for internal function signatures!

-Sara

Re: [PHP-DEV] Allow zero parameters in array_merge()?

[Sara Golemon]

On Fri, Jun 14, 2019 at 12:15 PM Benjamin Morel 
wrote:

> I'm wondering if there's any reason why array_merge() doesn't allow zero
> arrays to be passed?
>
> array_merge(); // Warning:  array_merge() expects at least 1 parameter,
> 0 given
>
> It would be reasonable IMO to return an empty array in this case.
>

I don't see any issue with this plan. I say do it.

-Sara

[PHP-DEV] libsodium based Argon2i(d) password_hash()

[Sara Golemon]

I intend to move  https://wiki.php.net/rfc/sodium.argon.hash into voting on
Friday.

Note that I need to update the PR to reflect the decision to synchronize
the time_cost and mem_limit defaults for libargon based hashing with
libsodium.

If you have any last minute issues with this RFC, please bring them up now.

-Sara

Re: [PHP-DEV] libsodium based Argon2i(d) password_hash()

[Sara Golemon]

On Thu, Jun 20, 2019 at 2:34 AM Nikita Popov  wrote:

> On Thu, Jun 20, 2019 at 12:54 AM Sara Golemon  wrote:
>
> > I intend to move  https://wiki.php.net/rfc/sodium.argon.hash into voti
> >
> > For "threads" (p=# in the hash output), the current PHP default is 2,
> > while libsodium is hardcoded at 1, we can't override that.
> > ng on
> > Friday.
> >
> > Note that I need to update the PR to reflect the decision to synchronize
> > the time_cost and mem_limit defaults for libargon based hashing with
> > libsodium.
> >
> > If you have any last minute issues with this RFC, please bring them up
> now.
> >
>
> Could you please explicitly specify what the new default time/memory cost
> factors will be?
>
> Done.


> Also, what is going to happen with threads? I assume the default will
> become 1, but what happens is a larger value is specified while libsodium
> is used?
>
> Default to 1.  Users will be allowed to specify higher numbers, but the
sodium implementation will produce an error with values > 1.

-Sara

[PHP-DEV] [RFC][VOTE] Argon2i(d) password_hash() via ext/sodium

[Sara Golemon]

https://wiki.php.net/rfc/sodium.argon.hash

It took me an extra couple days to update the diff and finalize the
language of the RFC, but it's ready to go and voting has been opened.

-Sara

[PHP-DEV] Re: [RFC][VOTE] Argon2i(d) password_hash() via ext/sodium

[Sara Golemon]

On Sun, Jun 23, 2019 at 12:25 PM Sara Golemon  wrote:
>
> https://wiki.php.net/rfc/sodium.argon.hash
>
> It took me an extra couple days to update the diff and finalize the
language of the RFC, but it's ready to go and voting has been opened.
>
Okay. Voting closed. Passes 30:0.  I'll merge this by tomorrow evening.

>
-Sara

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Sara Golemon]

On Sun, Jul 7, 2019 at 3:45 PM Theodore Brown 
wrote:
> For those voting against adding these functions, can you clarify why?
>
Explaining my non-vote.  I'm explicitly abstaining as I don't see the value
in these functions (I'd rather see a community driven library which does
the same thing in a more agile way), but neither do I see much intrinsic
harm in allowing these functions in.

I did vote against the mb* variants as I'd like to see those die in favor
of ext/intl in all ways and every way.

-Sara

Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?

[Sara Golemon]

On Mon, Jul 15, 2019 at 8:39 PM Arnold Daniels 
wrote:
> PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE.
> This behavior once made sense because of Register globals.
> The explanation in the manual also still implies that query and
> post parameters are converted to variables
> (see
https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names
).
> Register globals has been removed since 5.4.0 and thus this behavior
serves little purpose.
>
> I think it would be good to remove the conversion in PHP 8, as it's a
general cause of confusion and annoyance for anyone who comes across it.
>
> Is there a good reason to keep this behavior in PHP 8?
>
IMO, we can safely kill this.  If anyone needs this behavior preserved, it
can be mimicked with half a dozen lines of PHP, or heck we can include a
function to call.  I will, however, be very surprised if anyone misses this
by now.

-Sara

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Sara Golemon]

On Wed, Jul 17, 2019 at 4:19 AM Christoph M. Becker 
wrote:

> the quick fix descriptions of bugs.php.net[1] need some update.  To my
> knowledge, these come from the database, so could anybody with access to
> it please take a look?
>
>
Yep. bugdb_resolves table.
How about though, instead of requiring someone with direct DB karma to
update these, we just make an admin page for editing them directly on the
site (for a suitably limited population of logged in php.net users, of
course).
https://bugs.php.net/admin/?action=list_responses is halfway there, just
need a POST handler.

-Sara

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Sara Golemon]

On Thu, Jul 18, 2019 at 6:10 AM Christoph M. Becker 
wrote:

> I agree that this would be the best solution in the long run, and it
> shouldn't be hard to adapt ReasonRepository[1] to read from a file
> instead of the DB.
>
> Any volunteers?
>
> [1]
> <
> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
> >
>
> Sure.
https://github.com/php/web-bugs/commit/4b52935a8675d6ff6d5b06258e6c74ef135fad35

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski  wrote:

> It's available here:  https://wiki.php.net/pplusplus/faq
>
>
It's possible I missed something while on holiday. There are certainly a
lot of messages to page through.  I dig the idea of resolving this
tug-of-war between progress and BC, but I'm not 100% clear on what the
final goals are.  I understand that we're talking about more aggressively
breaking BC in this new mode while preserving BC in "normal" PHP files, but
I think it would help the conversation if we enumerated specific aims.

Some guesses on what we're talking about:

1. Short open tags.  This is probably the ugliest nut to crack since it
can't even be guarded on a declare directive.  Adding a new open tag
doesn't really fix that though, it just changes the specific shape of the
problem.  Unless you add an INI for disabling PHP mode.

2. Strict(er) typing - I'm not sure, on the surface, what future expansions
we'd plan for in this area which couldn't fit into standard PHP in a non
BC-breaking way.

3. Failing closed. Things like strpos() being able to return int(0) which
is a falsey value. This has been a long standing "complaint" about PHP
which isn't actually "fixable" without a big BC fail.  We've already shown
we're willing to bite this bullet for security issues
(openssl_random_bytes).

4. Argument order/Naming consistency. I have little respect for this
complaint about PHP, but perhaps this is an assumed goal?  If it is, then
the reusability of the majority of the runtime comes into question since
anything we "fix" in P++ needs to have branching and/or multiple
implementations.

Am I *completely* off base?

-Sara

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:30 PM Mark Randall  wrote:

> On 09/08/2019 22:02, Sara Golemon wrote:
> > 2. Strict(er) typing - I'm not sure, on the surface, what future
> expansions
> > we'd plan for in this area which couldn't fit into standard PHP in a non
> > BC-breaking way.
>
> Union types and general reflection do spring to mind on this. I assume
> any APIs using them would need to return more complex objects describing
> them, rather than individual strings from getType().
>
> Or maybe a string from getType() and an object from getTypeAnnotation() ?


> Typed arrays are also another one which has been in high demand that I
> imagine will present some BC issues if shared between stricter and
> less-strict code.
>
> I don't see these (or Generics which you also mentioned) as being
inherently incompatible between more/less strict codebases.
Say we have an array or ValueObject in "more strict" code, we
could refer to an unspecialized version of that as merely "array" or
"ValueObject" in "less strict" code.  Or even not refer to its type at
all.  Without a formalized proposal for how these are implemented, I'm not
sure we can assume there will be technical challenges which we simply can't
overcome.

My point being, I'm not sure these things necessarily require a schism.  We
should be certain they do before we invest much time in figuring out the
how of it.

-Sara

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski  wrote:

> As Bob pointed out I'm rusty, but I do think that we can solve the short
> tags issue in this way.  At the lexer level, if we see the  tag, we
> set short tags to off for the scope of the file before moving forward.  But
> more importantly, this approach can allow us to implement different BC
> breaking strategies (and not just for language features, but also for
> built-in functions).
>
> That approach did occur to me to, but as I said in my earlier reply, I
don't think this actually addresses the goals set by the short tags removal
proposal *as I understand it*.  Maybe it does, but for example one could
still not start a file with "

Re: [PHP-DEV] Re: P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:30 PM Zeev Suraski  wrote:

> In the spirit of my response to Bob, I added a new FAQ:  "How does this
> differ from Nikita's Editions idea?"
>
>
"""Related to rollout - the Editions approach doesn't allow for just two
dialects - but any number of dialects. We could have a PHP2020 dialect,
along with a PHP2022 dialect and a PHP2027 dialect. If we keep them all -
this may actually increase our maintenance complexity."""

I don't think we would keep them all.  We could set a sunset cycle for
dialects similar to branch support cycles.   PHP2020 comes out and we
support that along with PHP1996.  Two years later, we introduce PHP2022 and
we continue to support 2020 and 1996.  When PHP2024 comes out, we drop
PHP1996.  When PHP 2026 comes out, we drop PHP2020, etc

This does introduce a point where legacy apps must fix their code or simply
not upgrade, but it also provides a path to upgrade to latest support
version, then migrate files one at a time to that version's latest,
allowing an update to latest-latest.  This is significantly better than the
current state of syntax BC breaks which requires all updates to occur WITH
the upgrade.

Meanwhile, we have a little more work (work you and Niki are both
suggesting we take on already), but with a bounded cap on how long we carry
complications around.

-Sara

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

[Sara Golemon]

On Sun, Aug 11, 2019 at 3:44 AM Nikita Popov  wrote:

> What do you think about this? As we are currently annotating everything
> with types, and we're at a major version, this would be the ideal time to
> make this change. But there's certainly a BC break here. (And, for the
> record, this is not the type of BC break where P++ or editions help,
> without creating a larger mess.)
>
> I think your original proposal was spot on.  It added to the language
without creating any BC breaks. The ideal outcome.
This modification adds an admittedly small BC break for an equally small
benefit.

-1 from me.

-Sara

P.S. - Perhaps a way to the middle might be to introduce implicit return
type hints.  If a child method is implemented with no return type specified
on a parent method which has one, then the parent's type is assumed at bind
time, then we provide a better runtime error if that assumption is violated
in a strict_types=1 context which is the only place where strict covariance
of return types matters to PHP.

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

[Sara Golemon]

On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov  wrote:

> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon  wrote:
> > P.S. - Perhaps a way to the middle might be to introduce implicit return
> > type hints.  If a child method is implemented with no return type
> specified
> > on a parent method which has one, then the parent's type is assumed at
> bind
> > time, then we provide a better runtime error if that assumption is
> violated
> > in a strict_types=1 context which is the only place where strict
> covariance
> > of return types matters to PHP.
> >
>
> This is an interesting idea. There's still a BC break here, but it's more
> limited and only applies to code that is actively violating type contracts
> (that were previously implicit). Imho this should not be bound to
> strict_types though: strict_types controls coercion behavior of scalar type
> annotations, and nothing else. It should not be overloaded with this
> additional meaning (and I don't think the BC break is nowhere near large
> enough to justify this overloading).
>
> Fair.  Just trying to tread as light as possible, but there is a vanishing
point.


> Do you have this in mind as something for use by internal classes only, or
> as a general language feature? I can see the use as a general language
> feature (see for example the debacle where PHPUnit added "void" annotations
> to some methods). The migration problem of adding return types is certainly
> not limited to internal classes. On the other hand it does seem somewhat
> weird that an (inherited) return type will be enforced that was not
> explicitly given in the source.
>
> I agree that it would be as useful to userspace classes as internal ones.
It would allow library authors to embrace strong typing without breaking
consumers who are already conforming to docblock types.

It's probably worth proof-of-concepting this and making an RFC irrespective
of the push to annotate all the things.  If feasible and accepted, I'd be
much more on board with including return types for internal methods in that
plan however.

-Sara

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

[Sara Golemon]

On Sun, Aug 11, 2019 at 8:24 AM Nikita Popov  wrote:

> After thinking about this a bit, this is going to be pretty hard to
> implement. Currently return type checks are performed using a separate
> opcode, which means that we need to know the return type at compile-time.
> At the point where inheritance happens and we know the parent return type,
> we are no longer able to modify the opcodes of the function. We'd have to
> integrate the return type check into the main return logic, with a possible
> negative impact on performance...
>
> Well, we certainly can't do it without some perf impact. 100% agree
there.  The naïve and simple solution is expensive enough that I'd agree
it's not worth doing.  I can see a path to get fairly close to zero, but at
the cost of a non-trivial amount of complexity. Hrmmm  Yeah, ultimately I'm
not sure that gives us enough to justify the cost.

Okay, forget that tack pending someone being able to come up with an
implementation that doesn't suck.

-Sara

On Sun, Aug 11, 2019 at 8:24 AM Nikita Popov  wrote:

> On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon  wrote:
>
>> On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov 
>> wrote:
>>
>>> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon  wrote:
>>> > P.S. - Perhaps a way to the middle might be to introduce implicit
>>> return
>>> > type hints.  If a child method is implemented with no return type
>>> specified
>>> > on a parent method which has one, then the parent's type is assumed at
>>> bind
>>> > time, then we provide a better runtime error if that assumption is
>>> violated
>>> > in a strict_types=1 context which is the only place where strict
>>> covariance
>>> > of return types matters to PHP.
>>> >
>>>
>>> This is an interesting idea. There's still a BC break here, but it's more
>>> limited and only applies to code that is actively violating type
>>> contracts
>>> (that were previously implicit). Imho this should not be bound to
>>> strict_types though: strict_types controls coercion behavior of scalar
>>> type
>>> annotations, and nothing else. It should not be overloaded with this
>>> additional meaning (and I don't think the BC break is nowhere near large
>>> enough to justify this overloading).
>>>
>>> Fair.  Just trying to tread as light as possible, but there is a
>> vanishing point.
>>
>>
>>> Do you have this in mind as something for use by internal classes only,
>>> or
>>> as a general language feature? I can see the use as a general language
>>> feature (see for example the debacle where PHPUnit added "void"
>>> annotations
>>> to some methods). The migration problem of adding return types is
>>> certainly
>>> not limited to internal classes. On the other hand it does seem somewhat
>>> weird that an (inherited) return type will be enforced that was not
>>> explicitly given in the source.
>>>
>>> I agree that it would be as useful to userspace classes as internal
>> ones.  It would allow library authors to embrace strong typing without
>> breaking consumers who are already conforming to docblock types.
>>
>> It's probably worth proof-of-concepting this and making an RFC
>> irrespective of the push to annotate all the things.  If feasible and
>> accepted, I'd be much more on board with including return types for
>> internal methods in that plan however.
>>
>
> After thinking about this a bit, this is going to be pretty hard to
> implement. Currently return type checks are performed using a separate
> opcode, which means that we need to know the return type at compile-time.
> At the point where inheritance happens and we know the parent return type,
> we are no longer able to modify the opcodes of the function. We'd have to
> integrate the return type check into the main return logic, with a possible
> negative impact on performance...
>
> Nikita
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Sara Golemon]

On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:

> https://wiki.php.net/rfc/p-plus-plus
>
> To follow up my no vote; What I'm against is splitting the language on
hard boundaries that never disappear, only widen. I'm also a 'No' on
Editions, but slightly less of a 'No', and possibly a 'Yes', if those
editions are clearly intended to fade over time.

-Sara

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

[Sara Golemon]

Hi,

PHP 7.2.22 RC1 was just released and can be downloaded from:

https://downloads.php.net/~pollita/

Or using the git tag: php-7.2.22RC1

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
7.2.22 should be expected in 2 weeks on August 29th, 2019.

Hash Values and GPG signatures can be found below and at:
https://gist.github.com/sgolemon/f252c07fe09ce2acc0343b54417edb74

Thank you, and happy testing!

Regards,
Sara Golemon & Remi Collet

php-7.2.22RC1.tar.gz
SHA256 hash:
8fe0048a7e11074054fdc4bc0fdfce3ca1857fa13db5c30a9be86444aab1b6f8
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdU0ZKEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJiiw//
ZDuKLkRBqQSHvNryyb7LVik9SvsOYk+obFNGGw3MUCyokPZFPO0QnlEJMZUDWlG4
VEH4243O3zQzbuVHyYFJmBikcVvn6J3FE6HRbfnaqMDBSeWbUrt4kv+AZioo9d2k
go8HPGQjaJis4YSxU29oeMUqPdYusEs/GQY/2ICoGgTGORu/nFFtvlR6CDX06mCr
JcNDwbfBQpfE266rz6terEvQ8j+5fBW2JbU6JPS8udBlhwYOPdWcfYPfXiXmH4k0
o6oo6S36O30YsHF4vxgg8YP0kQvzx8+6r2g4anRBGZemZaNN2s6ikRwbgNHItmrm
QoTaOE+cfbNR9Iuj4APqdbhoO1mgjtmwRP/38s3dbYzLfmsWrbn+1Di2v7zcb7e2
79wiXcFmFCNCdSwik//EX8Mm872SvgGhTG1pzwpdllVNTjV/SldZVJEdMci536rt
JXh3CkItNkeakrYDo4OjXzmWjnBHBpBCGRBzAR35ePydHzh0U8t5OqkPniBdRzb9
8rSsUqHKBSVl7ZEYi8ZH2iglBDXrnKtSGMw3XRByXzJJIGmN09p6w3MGsT48KK9s
du9E349Aoq0H18AoWzkaFwokTJ78a6Pb0gXANKnjYT5gXIo07G4y+1UHX77jGT59
tq/z3bsXw11O0pVYZj6fKyjWj/XjPV/K/pr3ooVSkuA=
=um1t
-END PGP SIGNATURE-

php-7.2.22RC1.tar.bz2
SHA256 hash:
4a2ec2902818aaf34034b9a72b1cf1c260043840d08210ec3595c1541acd7f0e
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdU0ZNEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXLMiBAA
xWhyM5dDHkeRIzKVllvxiRGB+o28dYaJ1Ot4G26CEHqS2k1n23DECNZQaOLy9QTo
+rUQMmWIQRN9Nvu5k6HJBYbPBRDyOG7UhqUNfaXFfVI7F1+vBs3wxpisXvv5hdXs
T6tCUchA3o+yLc3uiuY71es4i5nau2t/QzBCp1mgDv/GLECP2rVv6CMnjsf9fOpV
BtUoHNupApjnedlJY8Y1bPk7r2lssihmPUrYHB+T1eo7OJS79JKIVNrYVSwAUrc7
8ctsyP2YRqDzcS/3mCKoV21khmp4KVuezw1goL15a3Gmdt8kLGT9GiJZF5Z5wqDB
PZnMyw2PdqTc8gAjm5zaouXneUi+riimfZ+H6ImX8S9me0j6v7HITRxsgBgRnJBm
oH4th/kYCERdEauk913y85cXG0JnMN+fYyqbjnRFRGRs11oyXoy89Y1HTRVTbyQ5
aDTf1Bolu5YRtziZT4G45ywXXCWvgIAE8Myj49AaIIK5gDBY/M380D7GVv+jkjv7
kU5mjDHxemqx7fbze+uN4g9czoTXbdadsdSXSKTkYizyWPP0h7Bt6AZy8HD5rYfF
/Br4VNhHZWH3bvihBG1S/kQsXzp3PjXIFqcYxRKFQJmbqYuJcbobVzoekej0uK2y
tEA47Ws7BHzuX62OgJeEA8DRGGOo38w4BvDP89Rhjzs=
=ec4D
-END PGP SIGNATURE-

php-7.2.22RC1.tar.xz
SHA256 hash:
c80a71b862fdb1fbb4eca2fd9d7668de79685a815e17e378452ddf22b91936f7
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdU0ZNEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXLXYxAA
uwvkoPLBRpin9p/osF7cGFwwUbAnRp1Kckl//skDCIPIzu1VCP1hwovtDHqlMotG
+OGa+ZzPc2zI1f9oqvnE6BHfKSBbKsCjP7hUmSLZ0z6GuCsKk3ySQdexVznYCROC
F8R5VFefCL4bMe23sj+8DlKs1Bl7L3+c1lb1r3CJai89pXCQpzQNKQNx6+BcV10m
mgVOGjCRABiHuYzbwKjiAJj5FqcUJe/5ZFcKlKRci0AvCiy35Xi67z1HlKOdKL8n
o1HGazoGHjV+1KboALNTG7f5SUZP/B/BsGBUSXEEsRooi8J94IjBGkRusp9nr+No
A8PUr+QL9r75Cj9oB94UC5MBepGyb7OPfotRw8IRtcniSsBvAnuCgg/WkdRUmMVF
MDiSjrzBxUrtZjXfKUymSfKYlQURSltDwQxHReneYfc2eS83Z5o2IDjph0MJ3IxY
LfYm7SzqjPUV96yx87krH0hbRWRacHw4YPSWQpEx6qAMV4TPmamRCW8kU8C6G5nb
8bdNZZPxC1ioK3pHkg6Oma4WYL73VyTzCQ0J/hv6+jvLO4OI6ygZTx+fghYUGi2n
3pP0ylHtpquUw/nrsRWqdZgQJ/CHqBYmExgI24yRdtsU0DPwKqBhao3NIcZK4pcZ
us4UIFjsG93qQ7wMq8j8b54UuIAOh681edMQTRGJ+pg=
=6BTw
-END PGP SIGNATURE-

Re: [PHP-DEV] Removing old branches in php-src

[Sara Golemon]

On Sun, Aug 18, 2019 at 6:06 PM G. P. B.  wrote:

> It seems this topic already has been raised a year ago [1] but nothing has
> been done.
> So I would like to raise the issue again, there are a various of old and
> empty branches currently in git, would it be possible to remove them?
>
> 1/ Which ones *specifically*?  Some release branches are empty only
because they didn't need to be patched after release (and our release
process was different).  Some are old and even "abandoned", like the
first-unicode-implementation, but they serve a useful historical purpose.

2/ Why?  Git branches are lightweight and don't really impact the project
in any way beyond enumerations.  I'm not against getting rid of truly
pointless branches, but I'm also not sure what the appeal is.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 7:51 AM G. P. B.  wrote:

>   - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
> knowledge to add endorsement names on the counterargument to the RFC on the
> RFC itself  when the appropriate place would have been the counter argument
> document.
>
> This has been a topic of discussion in the past. The agreement was that
non-author edits are permitted if they are isolated to a clear
"counter-arguments" section.  If someone had changed the meaning of the RFC
or of your arguments in favor of it that would be another story, but that's
not what happened here.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 12:44 PM G. P. B.  wrote:

> > This has been a topic of discussion in the past. The agreement was that
> > non-author edits are permitted if they are isolated to a clear
> > "counter-arguments" section.  If someone had changed the meaning of the
> RFC
> > or of your arguments in favor of it that would be another story, but
> that's
> > not what happened here.
> >
>
> Gotcha so from now on I'll just add a sentence "George Peter Banyard
> supports this RFC" every time I'm in agreement with an RFC to the RFC
> because having your name tied to a vote is apparently irrelevant, because
> this is exactly what you did (but only on the RFC not the counter argument
> page).
>
> Gotcha. So you're not actually conversing in good faith. That's helpful to
know.

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Sara Golemon]

On Tue, Aug 20, 2019 at 1:05 PM Влад Макин  wrote:

> I would like to propose a little change in var_export function behavior.
> For today, this function returns string representation of array in old
> style with “array” keyword:
>
> var_export([]); // array()
>
> I think it would be better if the function returned array representation in
> modern square brackets syntax:
>
> var_export([]); // []
>
> I do like the idea of doing this, and would even be generally okay with
just making always work that way since the introduction of square bracket
syntax is really *quite* old.

The only people I could see being bothered by the change in output would be
automated code-generation suddenly seeing a (potentially quite massive)
diff as the bracket style changes.  As an example,
https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
line var_export() generated list.  I'm actually /not/ bothered by the idea
of having a big point-in-time flip of that structure, though I'd want to
make sure all RMs switch versions at the same time, otherwise it could get
noisy.

Perhaps an option to quell any dissent might be to add a third param
$options to allow controlling this behavior.

function var_export(mixed $data, bool $return = false, int $options = 0):
string {}

And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
whatever you want to call the constants depending on which behavior you'd
make default (and honestly, I think we'd make the existing format default).

-Sara

Re: [PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Sara Golemon]

On Tue, Aug 20, 2019 at 1:58 PM Jan Ehrhardt  wrote:

> Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
> >PHP 7.4.0beta2 has just been released and can be downloaded from:
>
> Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
> https://github.com/php/php-src/releases/tag/php-7.4.0beta4
>
> Yes. Counting is hard. Also, skipping version numbers is a proud PHP
tradition now.  RMs discussed it and we're just gonna roll with it.  There
are plenty more digits in the computer.

-Sara

Re: [PHP-DEV] Re: PHP 7.2 minimum ICU version

[Sara Golemon]

On Thu, Aug 22, 2019 at 2:28 AM Christoph M. Becker 
wrote:

> On 22.08.2019 at 01:17, Trevor Rowbotham wrote:
> > Is there any way to increase the minimum required ICU version in PHP 7.2
> and 7.3 to
> > at least 4.6, which would ensure that the upgrade path is actually
> available to users
> > trying to avoid the deprecation notice?
>
> We usually do not raise any dependency requirements for stable release
> branches, to avoid potential BC breaks.  And after all, most of ext/intl
> is supposed to work flawlessly with such ancient ICU versions, and to be
> able to get rid of this deprecation notice, building with a newer ICU
> version is already possible (and, in my opinion, recommendable anyway).
>
> Agreed on not raising the library dependency requirement in branch, but
perhaps we can smooth the transition a little by only raising the
deprecation notice *if* the environment actually allows using the
non-deprecated behavior.  This would have the opposite impact on the active
branch of raising the dependency while still providing the facility of a
deprecation notice to builds that aren't based on ancient ICUs.

Or perhaps tailor the deprecation warning a little? (Nevermind, I just
wrote it out and it gets ugly)

Or perhaps just stick with status quo and add a note to the manual. :D

-Sara

Re: [PHP-DEV] Remove special Zend karma

[Sara Golemon]

On Fri, Aug 23, 2019 at 3:33 AM Nikita Popov  wrote:

> Any objections to dropping this and have a single php-src karma for the
> whole tree (with the exception of php_version.h, which is used to prevent
> bad merges)?
>
> No objections from me.  This divide dates back to /long/ before the RFC
process.  We've gotten much better about not "cowboy" committing things
without discussion.

-Sara

[PHP-DEV] PHP 7.2.22 Released

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.22. This is a security release which also contains several minor bug
fixes.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.22 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: http://php.net/releases/7_2_22.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.22


Many thanks to all the contributors and supporters!


Sara Golemon, Remi Collet

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Sara Golemon]

On Thu, Aug 29, 2019 at 2:29 PM Stanislav Malyshev 
wrote:

> >> I knew it worked, but I always considered this to basically be
> >> the PHP equivalent of undefined behavior in C. And I don't think anyone
>
> It's not. It's very well defined behavior, that is not going to break -
> unless it is broken intentionally in a zeal for adding more strictness
> for the sake of strictness. So, another thing to learn. I love learning
> new things, and love helping others do so!
>
> It is well defined. It's also, in my PERSONAL opinion, gross AF.  That
doesn't make me right or better or anything other than opinionated.

Other opinions:
* I'd quite like PHP to be a little less gross in places like this.
* I think Nikita's hitlist here is a step in the right direction, however...
* I DON'T think the cost to BC is justified in all cases. For example, an
exception for read of undefined vars is traumatic BC.
* I think declare(strict_types=1); already solved a very similar problem
and could easily be applied to future issue like this.

So how about we suck it up, put on our big girl panties, and just embrace
declares (including namespace scoped declares and/or a modern version of
.htaccess)

-Sara

Re: [PHP-DEV] Re: State of mhash?

[Sara Golemon]

On Wed, Sep 18, 2019 at 6:39 AM Christoph M. Becker 
wrote:
>
> On 17.09.2019 at 16:25, Nikita Popov wrote:
> > Should these functions be deprecated? Should this compatibility layer be
> > kept indefinitely?
>
> The documentation[1] states for more than ten years now:
>
> | This extension is obsoleted by Hash.
>
> So I think actually deprecating these functions for PHP 8 is appropriate.
>
Given that the mhash compatability shim is literally just "map this
function and args to that function and args", this one feels like a
no-brainer.  Anyone who can't upgrade because of /this/ change can
literally just drop a single (short) PHP script into their program to
polyfill those APIs.

It would be a kindness for someone to provide that, and if nobody else does
I may just drop a package on composer in the new few months.

+1

-Sara

Re: [PHP-DEV] [RFC] Union Types v2

[Sara Golemon]

On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
wrote:
> The choice of supporting precisely the two literal values `null` and
`false`
> is not arbitrary: They are the two values that are the most often used as
> sentinel values (for indicating failure or absence). It is true that
`true` is
> also sometimes used as sentinel value (more rarely and not among the
> internal functions), but the same can be said of other literal values
> (one of your examples includes `0`).
>
While I personally think `false` makes sense as an allowed "type", I also
don't want to see the union types RFC get held up on such a tiny detail.

I would propose either of the following alternatives:
1/ Remove `false` from the proposal. It can always be added at a later
time, but not taken away.
2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
also be subject to a 2/3 majority in order to pass.

-Sara

[PHP-DEV] PHP 7.2.23 Released

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.23. This is a bugifx release.

For source downloads of PHP 7.2.23 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: http://php.net/releases/7_2_23.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.23


Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet
Manifest: https://gist.github.com/sgolemon/67d27728418a4dc3c56d692af30caa18

php-7.2.23.tar.gz
SHA256 hash:
b32b426c84ff45154d6c11f00aff433bcac831a5c0a09bf0297075eefaea8fcc
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdimY6EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIbnBAA
rjmv2NzOCICkUnkJcZZ0ASRX3PwecGjjOtRHzlDCxmBQLBVaf5neNC1iZwjgUCdL
66+578wOfQUY76fuWPU+7EOa/Sk5ZsPu308p8aHE5n37t2B6lFS5wG8MHU8Gax3M
c7eiADgEfNj8ap1GqAwQ2BGq2EdXoYKAt4rHS771nT/run331j7MLextajZsppB9
dBLe8QZN7WV0WLNk5rGmcKvdfxMB46ucOrKE9H3UPTUQEhkBYELHALhhw9YzrccG
mtl+yfl19EhFs9wv+O8QNAt+I4TnOCXueLDV8Nhcw/JpiTCwSSKH8z4smIAEqUXA
UlcEGybES96YxsOrGfDE+HZMGPao7gSIfdl0XVkZa95m/YXoXmWBIHy8NymAsOM0
Vf7NQ3UGr2fjph0/D6dfQO664Qg0DolbQcLSFywvMgNjLRh4w3uOeZvWcGBie0H4
gJNwhr0GPji92lWVKGkW6YZY/58QRzue/FlwGX5aGwVOO6IIHzpP9axgzBhl5WSu
WuHF4eHyqvUgq6mTj2qTsUr+2bqJ0W87CtBfm+tcjJGwOw+j9KSEl+Rsmy0JS94W
Cc/BdAIaY/3n8uwd0g/5EoZC/SGtAHKPSspoPWrIuy+VcCQpfU8BWaUNqz1d6tMB
VRGUVO/J5rXPC/CAuI+DnEJDDsgP3kJsTpNMHGL9OVg=
=NSOS
-END PGP SIGNATURE-

php-7.2.23.tar.bz2
SHA256 hash:
a17af3643d29d7e730f977e3776dc3e325d5ca00b361e41dbfc2368ebad5430d
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdimY9EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJmKxAA
gzRXvrlj3Hs09+77hxd3XoR88p1hvM6jEHTyMUyf6Bi2TjwWP2CZUy53baqS+NtY
iUNQIpXASC5vD56MmGqVKGWCFzCIt2gGJuxXQ6k0PLN4/Ku83bbX/PH8qxciPxr2
csR++12OkRZApdUzYcrWYL/UUHcd2UCHiQ+u/tQ9Gr5636x6IhT1Oeyu5k8hwaZu
oQTK2aIUZ7AYB37hg+rgF616hcMHZ2Kzeieej8b37qIUmEETWMO4YHfJ/4XYoGus
Z+wTJNQnXcAXx7MBSfWOZRsrUALaxuEg10MJoABrodip83XvwL9MVeTJMbzGAg4V
B+CN5fKefB6TkZHJyKj7yre1eEGy4KX9hOO9dKjcT41numO9pjBfQq9FBL/Gd+MJ
XnG/lDscFpqNayp+dMxquhY3PKDjFqVjT+O1hP36RGVu09+IOLkKzZRQrEdgJud1
mJG4WE4VsAUq6lKR1DAVq7atfdiLeR2Z/t3i1OX1FTTSKoQJXxTgCVdS42Zkg3gM
rySAQHS5sFRTUo34g2YHfUGuFKb7YkdCON6KAc91gfEdUiFrDnxJoHOV3j2ZcpFn
PA4igxIqqZ+IovQzXSXlbVaTgOe4LSKBPNgXS1dL6PG5rFVlnFNJT56trFfm9d8u
ZNLfRDcmgTJoF39lk/gpdqVSxBzi1OCX6XGfRFhmPs4=
=bj/g
-END PGP SIGNATURE-

php-7.2.23.tar.xz
SHA256 hash:
74e045ec8ff26290db6a3688826dcdf43b87bc509e508e9cb76dab742804ca14
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJdimY+EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJ+og/+
IoKRBa6+X76fa8a7yyLlAoH952CRo/54iMSp+fiXrwQHT9NN8MPSBG7l3Gbtf14N
nn4VXxna1jyix8rlyHhIpTugGjSMetFm1H8SO71wgOKebPAIh9X/4kIaPHJxlsO7
X8iY77vtWhUap9Xy0V7HpVNn3D1mqW0g8f+GfObhnMZjqt42NR5SXOki4BgJYll6
X2nQa950BjU5PJWvDIvtxyBytOg760ovRVcnj2uEGKO9D5rMlH++/Nw+Wr3NOPHc
/iXsSfqEAjsWEWNRXmVTeQTWPGTuqUdYJDTSN5eW8d7wEKamz8VL2qHnOwvmxFt1
DYPraZLKCUyqDtiS04IsjeNdwJg0L9WipRtwdbTSdfRdcyHsQm5NxoLMdH5au1/a
jMivYI8yeqN+DYhdnci/TuuzRHe7nUYZqXLuXcHTUbw+pRSh4i5TD17jt+GphxoR
09hrMJo0EkO8PYQCqFZSi4/uv47lJmRu+tBW0vmMskcRvewzX4oMsVCVQsqM+5NR
DKAyXDdnf9gHb+eGQJ/njEWAH5PCzU/Rsc0CwbAXXmDQP3gjPNGHOUmnRQn4m8og
cjnOwx3GmR0K1FSFdJb/9gg5ta1ZblMmqzdu9X3miS+yaaGDBkSpvpyZORUEsJ/J
JsWF6+eBt1t2jZil280NVDrDID+EwX2QcHBFEQQvcy4=
=q1SA
-END PGP SIGNATURE-

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

[Sara Golemon]

On Wed, Oct 2, 2019 at 8:24 AM Nikita Popov  wrote:

> * The "Undefined array index" case. This one passed the vote with an exact
> 2/3 majority, so I'm a bit uncomfortable making changes here. This is also
> the only case where convincing usability concerns have been brought
> forward, primarily around the $array[$key]++ example. I'm not yet decided
> on what to do here and whether we should pursue additional library or
> language features first.
>
>
We raised margins to 2/3 to avoid having to feel bad about narrow
majorities.  I say this as someone who was quite tempted to vote "Keep
Notice" which on retrospect would have changed the entire outcome based on
that one vote.

If this had been a simple majority vote and it had pass by like
52%-48%, then obviously that's not a mandate worth making potentially
catastrophic changes over, but this is 67% to 33%, it feels like you're
okay here.

-Sara

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Sara Golemon]

On Fri, Oct 4, 2019 at 10:45 AM Mark Randall  wrote:

> I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> discussion.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
>
> The argument that they're visually difficult to distinguish from a single
quote is valid (though IDEs with syntax highlighting mitigate much of
this), as are most of the arguments presented.  However, as with several
RFCs recently my overall position is: "BC breaks *must* have a justifiable
benefit to outweigh their cost."  The fact that so few people on the reddit
thread which prompted this RFC (yes, I read the internet too) were even
aware this feature existed points to there not being a problem which needs
to be solved.

The argument about it not being obvious that exec related ini settings
apply to backtick is silly and I'm going to ignore it.

-Sara

Re: [PHP-DEV] [RFC] anti-coalescing-operator

[Sara Golemon]

On Thu, Oct 24, 2019 at 4:55 PM Ken Stanley  wrote:

> > isset($_SERVER['fname']) && $user->setName($_SERVER['fname']);
> >
> > Will return boolean.
> >
>
> Just testing the waters: Is there any appetite to have AND and OR behave
more like Pythons operator?
Instead of now:
(a or b) => bool(true) if either of a or b are true
(a and b) =>  bool(true) is either of a or b are true

Behave as:
(a or b) => Value of a if true, b if a is not true but b is, bool(false)
otherwise.
(a and b) => Value of b if both are true, bool(false) otherwise.

Coincidentally, this change to T_LOGICAL_AND would server OP's purpose.

I'll tell ya, I'm leaning "No" because BC, but at the same time, AND/OR
seem to be underutilized constructs and I *suspect* (having done zero
research), that most existing uses would yield the same result as they do
now.

-Sara

Re: [PHP-DEV] [RFC] anti-coalescing-operator

[Sara Golemon]

On Thu, Oct 24, 2019 at 12:46 PM Stephen Reay 
wrote:

> This sounds like an alternative approach (for solving the same basic
> problem) to the nullsafe operator discussed a while back, no?

https://wiki.php.net/rfc/nullsafe_calls
>
> At the risk of hijacking, @matthewrask asked me about ?-> a couple weeks
ago (Javascript is making this one popular), and I threw together a rough
PoC at
https://github.com/php/php-src/compare/master...sgolemon:null-coalesce which
I suspect he intends to RFC properly soon.  As long as the topic is at
hand, what's the general appetite for it?  Should I bother polishing the
turd?

-Sara

Re: [PHP-DEV] Re: PHP 7.2.24 Released

[Sara Golemon]

On Wed, Nov 20, 2019 at 9:28 AM Jan Ehrhardt  wrote:

> Remi Collet in php.internals (Thu, 24 Oct 2019 12:58:01 +0200):
> >The PHP development team announces the immediate availability of PHP
> >7.2.24. This is a security release which also contains several minor bug
> >fixes.
>
> Is 7.2.25 stuck somewhere? 7.3.12 was tagged yesterday, but nothing for
> 7.2.25 yet.
>
> Sorry. I got busy with another matter and lost track of this task.  The
tags have been pushed and the tarballs are in the distributions repo.

-Sara

[PHP-DEV] PHP 7.2.25 Released (Penultimate bugfix release)

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.25. This is a bugifx release.

For source downloads of PHP 7.2.25 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_2_25.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.25

Many thanks to all the contributors and supporters!

Please note that with 7.2's active support terminating in 8 days, 7.2.26
(expected 19 Dec, 2019) will be the last regular bugfix release. After that
date, only security fixes will be included.  Users are strongly encouraged
to update to 7.3 or 7.4 in the coming months.
Read more about our support timeline here:
https://www.php.net/supported-versions.php

Sara Golemon, Remi Collet

Manifest: https://gist.github.com/sgolemon/6206424fc265a5be652b0a384816b387

php-7.2.25.tar.gz
SHA256 hash:
b2cb1bd46454d33b2c65c2fd559f464cd14e57dd47b953adf5caa77fdf0de52b
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJd1WI9EBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIMjxAA
16iB4ws078S2k19WzUx4eBp/olwde8A17grNDU2Jw/WH3svDB5zGkAuy3QQv4orE
CMXjHhdN/UztRnGy37A2wQo4/mOEek7aT+xYXAf6jPct1MYJ9upYlbwyLZddNk+Z
ZUQLOfqLLVn2yJG+pEHcaFTG+2l9V2TVLFuR9R1KaWWt74p9A29WN233rdprqYTV
VndGSYstDcZ9xYAdLr41qKdQGQCKFmTtd+ashn4xvZjZ1vb/+sh+t4Yf/NFbxbJL
+gJYd42KAPLxyMvz8ePKXDNz2Kf/JcJN0H41a7m/xZ7W3jJcr59JZzD0Vho1CguE
5AXtCXaQs/56GcOsnAELwVgqa2S7AHJ78D9tkT46s/GyOezRMQU3hhOM6c3CLKFq
+nKt75xYj1JeoebLbwCFMLWslvhyyDrc7L+CXxb8C8tpSv+XzQVetjmix6ICV6vV
ztxyskDtE0E9GXI1e87aric2MIhpmQI02QQYTWhd7YXdZre3739gF6bD3E9hVvgc
3o76UMN8hMxZGrIhQt00h8fMFsVVnOpD2DVMIdhhtHAtmHyUB40f6kINNcP/gGyR
d5TPGjEs4PcAZP+Ih4FHYAxyOfFOkk+VVOhlcJfdhkwZz6PNfX+ja0pVWNDIU9/b
cPsMCsFpSsCouFsn5EM3qqUfMMwaqUaPxURwZsustLk=
=7eoq
-END PGP SIGNATURE-

php-7.2.25.tar.bz2
SHA256 hash:
7cb336b1ed0f9d87f46bbcb7b3437ee252d0d5060c0fb1a985adb6cbc73a6b9e
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJd1WJAEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXLW5Q//
ellkAjkMOS1RdJqyNOtlzraxmfJZiHjnw+nf1bHdSiDS3X1OeKtqmx81vitj5kvi
bwPw4+nAeiq+J6onZU87Gn+5WnCbFAzJHOkIeyYSdgmVFpdvTszx+M/NgIce3kR/
gOOYTSepRA1qOGE2OCRT/zXRVSJhJ1cJX+kK3NMtkdyz6tGvdBtzoJbyctEWCfND
JGJnjo5ijVG8Ps/O6B94CyJ1pdiwYH5ET8HHU8G3PQwm945/X6DMfYb2HfzTFeS9
vulTM041lpjsvgST/NTeZGVfUtbHxILyPIn6lnBPWcbjw7d/oCbjZn8w3hHKMPQe
4TY+nBzBaWKN24kqVkZwRtk8J/qbXivrtoR4hISjwbs/9BZqDFzxiFD1SRDRe/i1
A/wBY3DY2vX9RVVRQyPWZLHt0z80ZgrtCEWhuGO7H39lFCgPWhv6NqaTeKOT6BoX
p7H/UbTAH26GV1R/DbxosoOJ6TCIpQrlbWu0yEqei9kL7QvY1M6RbgI8GAdHWPdf
Ha41l+db1T+eMdGr+uvxkOrsNhivJJokpAZ0tVXh6gcdEKHQJ7Ccrsci69LisJYz
fbZy8tshOB81HKMBGU4JTxNsRK4PJpNnwcwRPbt4x//5H9nr3/i4uFUo9+FCqO3n
OuNy8O2m+FLKo15/MWXs7YlqCKGj7vnoZdTfp4XduUE=
=2SlA
-END PGP SIGNATURE-

php-7.2.25.tar.xz
SHA256 hash:
746efeedc38e6ff7b1ec1432440f5fa801537adf6cd21e4afb3f040e5b0760a9
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJd1WJAEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXL65A/+
NtrRg8lyIhLd48MFq9/uWBwmV2Lpp/gWROJN1lL9WDbML/id4z22eTVNdGGONdZ5
4DPv6s/jBYc0nzt/lt0KEOY0maaja0JB/KBNqtB2cyFTaLUEqEw/ajWeO7Z2PBH7
y7L3Sm60N9WVl/S9kA5SR8Kt0DzvDCx6E6d9Uel9qDTiSjmElQ15BqsNDsGhAb/n
NAtXKkqlS0DefJ4SGFzPO5PtyqpDW/5jNp+00Aj7liTdHIWjZ6FnAaZ7Hc137RN7
muPGIBKlxQ01SoDxfIYgmd44oAujqHNzgXIM9US2dBXJF3zK+bknSNcdgquu9BD5
n0S0cyq10lsVonU1y7CFMbSXNsvwyL8tdIQtSBpSgbHirTfJ8J6RQjRPav7A58nt
KkzbXtIeOsiySGlGebTqL/mZw7cyg5VP95tp595OIIO2VT7jbIrE+WPragvlWEWu
qBDzPX6607qcUapLXNYNcyjXcdKTn/kN5kPro9A171lZuqNdH6iycBzn+ayKePH6
qfTMl4CAzt/8c2CQ/Em5kHALpXhmiJwGRwldUdxQZGqdKtuddVmCpzTNWi8W/pb0
xhlNExyhhooGGjVQ0YaO7jnjrizanzWk+ybreIXNmJYQJTQWaufxsIkp0sSW9bVk
eTxEctcbEz3EI3zPE1GMoISBD0C39lizRMo6QpvwW0U=
=HpgY
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Sara Golemon]

On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov  wrote:

> This has been discussed a while ago already, now as a proper proposal:
> https://wiki.php.net/rfc/token_as_object
>
> tl;dr is that it allows you to get token_get_all() output as an array of
> PhpToken objects. This reduces memory usage, improves performance, makes
> code more uniform and readable... What's not to like?
>
> An open question is whether (at least to start with) PhpToken should be
> just a data container, or whether we want to add some helper methods to it.
> If this generates too much bikeshed, I'll drop methods from the proposal.
>
> Yep. I remember bringing this up in 2016 and there was generally good
reception to it from you, Andrea, Stas, and Stig at the very least.  Why
isn't it in? It got derailed by some bike shed colorizing and a little bit
of workplace drama then dropped on the floor.

Thanks for picking it up, and I agree with your response to Larry.  As nice
as it would be to lazy iterate, the scanner is just in NO shape to tolerate
reentering userspace and potentially reinvoking the scanner before the
first run through is done.

I also agree that being able to subclass the token would be great, but that
PDO made some mistakes here and we can do that as a separate addition later
on if there's not consensus now.

I'm +1 for NOT overloading the token_get_all() function, but rather putting
a static factory method on the PhpToken class (or whatever you call it).
When we add subclassability, we can always add additional statics if our
initial signature doesn't work out.

I'm not clear why you want to final the base constructor.  IMO we populate
the fields on object creation, then invoke constructor (which is a no-op in
the base class).  Later uses of subclassing can deal with the properties
(or not) at that time, in their own constructor, delegating (or not) to the
base.

TL;DR  +1, because I wanted this four years ago. :)
-Sara

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Sara Golemon]

On Fri, Feb 14, 2020 at 7:44 AM Marco Pivetta  wrote:

> On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon  wrote:
>
>> Thanks for picking it up, and I agree with your response to Larry.  As
>> nice
>> as it would be to lazy iterate, the scanner is just in NO shape to
>> tolerate
>> reentering userspace and potentially reinvoking the scanner before the
>> first run through is done.
>>
>
> If this is the current state, maybe it would suffice to declare the return
> type as `iterable`, and return a strict (fully populated) structure in a
> first implementation, later to be changed to an iterator, if applicable?
>
> I think that's an optimistic, but ultimately harmless approach.  Arrays
satisfy Iterables.  Worst case we never improve on that. Best case we get
iterable token generators.
+1

-Sara

Re: [PHP-DEV] Make sorting stable

[Sara Golemon]

On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov  wrote:

> The only issue I ran into is that this change has a negative impact on code
> using illegal comparison callbacks like this:
>
> usort($array, function($a, $b) {
> return $a > $b;
> });
>
> Let's define what "negative impact" means in this regard.  Is it that one
still winds up with an essentially sorted array, but hitherto "stable
appering" output is now stable in a different way?  Or is the result
actually just NOT sorted in a way that a reasonable user would consider
correct (e.g. 5 sorted before "3")?

If it's the former, then I'm generally disinclined to be concerned about
the breakage.  We never made a promise about comparison equality
resolution, so moving to making a promise about it isn't violating anything.



> This kind of incorrect code will break under the proposed implementation,
> because we will now compare by original position if the comparison function
> reports equality. Because the comparator reports equality inconsistently
> (it says that $a == $b, but $b != $a), the sort results are also
> inconsistent.
>
> I read this user-space comparator as saying that values are never equal.
Sometimes $a > $b and $b > $a are both true, which is terrible.  But if
they never report equality, then position sorting should never come into
play.


> What do people think about this? Is there interest in making sorting
> stable? Is it okay to break code using illegal comparison callbacks?
>
> Generally +1, just curious about what breaks and how.

-Sara

Re: [PHP-DEV] Make sorting stable

[Sara Golemon]

On Wed, Mar 4, 2020 at 12:12 PM Nikita Popov  wrote:

> On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon  wrote:
>
>> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov 
>> wrote:
>>
>>> The only issue I ran into is that this change has a negative impact on
>>> code
>>> using illegal comparison callbacks like this:
>>>
>>> usort($array, function($a, $b) {
>>> return $a > $b;
>>> });
>>>
>>> Let's define what "negative impact" means in this regard.  Is it that
>> one still winds up with an essentially sorted array, but hitherto "stable
>> appering" output is now stable in a different way?  Or is the result
>> actually just NOT sorted in a way that a reasonable user would consider
>> correct (e.g. 5 sorted before "3")?
>>
>
> "Negative impact" is PR speak for "completely broken" ;) Yes, it could
> sort 5 before 3. The comparison function becomes completely ill-defined and
> you get Garbage-In-Garbage-Out.
>
> Roger that, thanks for explaining. 👍


> If we are concerned about this (I'm not sure we should be, but I've at
> least seen people be interested about this peculiar behavior:
> https://stackoverflow.com/questions/59908195/how-come-usort-php-works-even-when-not-returning-integers),
> there's two things we can do:
>
> 1. As Tyson suggests, we can throw a warning if a boolean is returned from
> the comparison callback (probably with a check to only throw it once per
> sort), to make it obvious what the cause is.
>
> 2. We can fix this transparently by doing something like this internally:
>
> $result = $compare($a, $b);
> if ($result !== false) {
> return (int) $result; // Normal behavior
> }
>
> // Bad comparison function, try the reverse order as well
> return -$compare($b, $a);
>
>
¿Por que no los dos?

Fixing broken stuff transparently for a smooth upgrade path PLUS letting
people know they're doing it wrong seems win-win and low cost.

-Sara

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

[Sara Golemon]

On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey  wrote:

> I’m currently working on a patch for this, so this might help with one
> aspect of your proposal.
>
> Here's a quick&dirty for AF_PACKET, looks like OSX/BSD might need AF_LINK
though...

https://github.com/php/php-src/compare/master...sgolemon:sgolemon.ngi-mac

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

[Sara Golemon]

On Mon, Mar 16, 2020 at 12:49 PM Ben Ramsey  wrote:

> > On Mar 16, 2020, at 12:48, Sara Golemon  wrote:
> >
> > On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey  wrote:
> > I’m currently working on a patch for this, so this might help with one
> aspect of your proposal.
> >
> > Here's a quick&dirty for AF_PACKET, looks like OSX/BSD might need
> AF_LINK though...
> >
> >
> https://github.com/php/php-src/compare/master...sgolemon:sgolemon.ngi-mac
>
>
> Yep. OSX/BSD needs AF_LINK.
>
> Updated for AF_LINK

Re: [PHP-DEV] PHP 8.0 Release Manager Selection

[Sara Golemon]

On Thu, Mar 19, 2020 at 10:27 AM Derick Rethans  wrote:

> With the first alpha of 8.0 due in three months, I think it's time to
> start the process of finding and electing release managers for the next
> release of PHP.
>
> Name put forward.   7.2 is in security-only, and it'll be EOL shortly
after 8.0 goes GA so I'm free to take care of a new release.   My process
is also already setup for concurrent releases since I helped out on
occasion with some 7.1 releases.

-Sara

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Sara Golemon]

On Thu, Mar 26, 2020 at 8:31 AM Nikita Popov  wrote:

> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
>
> Similar to an RFC you submitted six years ago:
https://wiki.php.net/rfc/automatic_property_initialization
I think the availability of typed properties makes the syntax for this much
more sensible and I look forward to +1ing it.

-Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Sun, Mar 29, 2020 at 3:43 PM Benjamin Morel 
wrote:

> This is the syntax I'm using in brick/varexporter
> , and supporting it natively in
> var_export() makes sense.
>
>
Ditto Danack's question, adding: "Then why not use brick/varexporter?"

-Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Mon, Mar 30, 2020 at 9:06 AM Benjamin Morel 
wrote:

> I don't see a reason not to follow with the short array syntax; the only
>> expectation of people using var_export(), AFAIK, is to get valid PHP code;
>> they don't care about the syntax,
>
>
If "they" don't care about syntax, then why do you?

-Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan 
wrote:

> @Sara Golemon 
>
>
>> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>>
>> -Sara
>>
>
> I punt the question back to you and ask why not use PHP?
>
> Simple. Because an implementation in script code is more agile, more
accessible, and more maintainable in the long term. It's better in every
way except default availability.  Considering the *1 line* required to make
it available in a project, this is not a compelling reason.  Conversely,
avoiding unnecessary breakage of existing code over a matter of aesthetics
IS a compelling reason.

Now, will you answer my question?

-Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel 
wrote:

> If "they" don't care about syntax, then why do you?
>
>
> Sorry I was unclear. I was reacting to the argument about broken tests in
> php-src.
> I meant: they don't have *expectations* about the syntax, but they'll most
> likely want to be able to read it.
>
> And we circle back to the current syntax being perfectly readable. We
could keep this up all quarantine...

In a more practical example,
https://github.com/php/web-php/blob/master/include/releases.inc is an
example of a var_export() generated file that lives in the wild and is
regularly updated.

I would say it's fairly readable, HOWEVER I WOULD AGREE WITH YOU that it
would be MORE readable using short array syntax and skipping the index
numbers.  In fact, I had exactly this thought nearly 3 years ago when I
started touching this file regularly. (plus the fact that the structure of
this array is kinda gross).

You'll note though, that I'm not championing making this file more
reasonable. Because it doesn't matter.  Because accidental damage to
existing code isn't worth a minor bit of aesthetics by a file which is
primarily read by machines.  If it really mattered to me in any meaningful
way, I'd write the dozen or so lines of script needed to output in a
"pretty" way.  Or I'd go google and find brick/varexporter.

Lastly, there are at least six RMs at any given moment working on PHP's
release.  Can you imagine if we were updating this file using different
versions?  The git churn would be horrific.  Do not want.  If we really
wanted "pretty var_export", then there'd be no real choice BUT to use a
library script to do the serializing.

-Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Mon, Mar 30, 2020 at 12:32 PM Sherif Ramadan 
wrote:

> Now, will you answer my question?
>>
>
> Simple.
>
Wrong. It's complex as this thread proves. Opinions are not in alignment
making it non-simple.


> Because an implement in php-src is more available,
>
Wrong. It's got availability FOR THOSE ON THE LATEST VERSION. It is LESS
available for those on older versions.


> does not appear to have a lot of maintenance overhead,
>
Neither does brick/varexporter, this point is irrelevant.


> is easy to implement
>
The format you want is already implemented.  Done is easier than TODO.


> and it's better in every way.
>
Wrong. Please consider reading my earlier reply.



> Given that code is meant for human consumption
>
Wrong. It is meant for machine consumption.


> I would say that conversely doing it IS a compelling reason.
>
> Wrong due to every part of your statement being wrong.

All the best.
-Sara

>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

[Sara Golemon]

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler  wrote:

> Just out of curiosity, is there any reason we couldn't add an optional
> parameter called "$short_array" or whatever that defaults to false? Then
> there shouldn't be any backwards compatibility issues.
>
> None at all, though I'd make it an `int $options = 0` similar to
json_encode().  I'd have a FAR easier time supporting that than a wholesale
BC break for the sake of breaking BC.

I can think of a few options:
  VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
  VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
  VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
  VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234} syntax
for UTF8 strings

Though I'm going to stay with my stated position that I would MUCH rather
this stuff live in userspace.  Just because PHP's penchant for
including the kitchen sink is broken already doesn't mean we should break
it more.

-Sara

-Sara

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

[Sara Golemon]

On Tue, Mar 31, 2020 at 6:49 AM Jakob Givoni  wrote:

> I've moved the RFC to the voting phase:
> https://wiki.php.net/rfc/compact-object-property-assignment
>
> On the third vote (which syntax would be better), I didn't vote because my
answer is "None of the above". They're all kind of awful.  I'm not against
the concept of COPA, but every option on there makes me search for the
"Nope" button, and I lack the imagination to suggest anything better.

-Sara

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Sara Golemon]

On Mon, Apr 6, 2020 at 2:36 PM  wrote:

> I have closed the voting. With 38 in favor and 28 against the RFC is
> DECLINED (didn’t reach the needed 2/3 majority for a new feature).
>
> Please don't be discouraged.  I did vote against, but I was on the fence
(My vote was 'Yes' for a period).  Review the feedback you were offered,
revise the proposal, perhaps even shrink the scope if that seems
appropriate.  At 38:28 I don't think we're far off of a version of this
feature which meets with success.

-Sara

[PHP-DEV] PHP 7.2.30 Released!

[Sara Golemon]

The PHP development team announces the immediate availability of PHP
7.2.30. This is a security bug fix release.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.30 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: <http://php.net/releases/7.2.30.php>
Downloads:<http://www.php.net/downloads>
Windows downloads:<http://windows.php.net/download>
Changelog:<http://www.php.net/ChangeLog-7.php#7.2.30>
Migration guide:  <http://php.net/manual/migration72.php>

Many thanks to all the contributors and supporters!

Sara Golemon

P.S. Below is the verification information for the downloads, which is also
available on
https://gist.github.com/sgolemon/ab0e2211fe2804bd250c1f906461e4df

php-7.2.30.tar.gz
SHA256 hash:
daa53d22510b0fd433904d1c3de460746860a974b776f727ac8acecb44e16e2f
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJeldthEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJ2HhAA
oY8hnKGDIhMEQ1w6dt9+jSAhgIsQmMDfQq28XWEO83uUiEuD64klm2vcbVQ7UkPU
YhzeT++ExIjGupg7k2sdQ/z1IfmjJiYGRyaSuTvaK4gyYEEJ7CgBbnCDIqoAWLQk
a3lqV/4h2wbosm9AxwNfGSoJZx0nFnJ16p+7FpQqUA5WaFW3h+XVatZhbZBp6ZpR
+a5radnTLpLXC9/kKks9xFCLRonjMVCySZ3QyZV4+P4IHAnM5vTP3dpZQz5K6Rj0
UnTFHEgnsggKQU1gSPGwh2ljPsKBkYXVbLNX3vs2+OOC6kSzI1JXPIoZQRI9xJuO
iHVRaEIpR9hPrv6f2BBZpnmZ9sEJTveDbaPpK4Tvp3GHJO8L8vbDdYb80GNdr06+
600x5VfcZ6zBhpWlSHqwz1OMukON9F+LTxDLqEbTrDnHPKEm5BaRoVpDlSZP5w0l
zCTWvrssrUIZCpFRBSukZQ2Hdb2azGuOmGclrX0Ef2NQZLTx+LaIBpMj5AmsUPJT
CCFfe7BlrLf8WCgWJKOjE4guFsCk+GhVtkkptds+sv67kN7sw1tbeARP6kCnzjzv
nNPGtWu0K6Oq7CJPA6cUb8fBwe7DxKGfPYFDTEOIT0EcosmfkQgxqvv/5gSda+U2
b82w7ukJ4IBKDGugazRO49+9LTowvIvYnkKCD0ClQho=
=JtDw
-END PGP SIGNATURE-

php-7.2.30.tar.bz2
SHA256 hash:
c4cf5c9debe8fd8def0a933231cf2fa3a8bdd22555ae57e825bfac6a87a712bf
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJeldtkEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJglA//
ZB3PTFOFtA7prjf0/SHd3cQTXtG6WbDpb9dW3LmRdsNrO9wlkQAJMC6BTR4wN2Zx
hsbpbdLXIRHZ/Oqm7cda/lWNt41rIFunm80dngjTm6ocipwi8GPV+3xfendcXepa
034jbMETu+3iYfo/JqM3f/rQsG+IL3JmD0j+pcWbBFyB2FCYqdSVIrlQ4iYneZfz
SFN6pcElOwwX/bVJ7J37Tmx+Hdtc0vgBBGtl9R2qBZugTKIaXHkYnudZzMEXc8ni
iYMtUvz9NRG1tH5whPi8EeeUdOjPoLgP+e76Om5I6CcSBEHalHUT4isXYDVP7Sd/
//xS43N3YeNEsLFOWkdPBcit5MZG4xvGquGe9GJHfkyKn892M8I5ywTOmmKgMn/v
hfVB98k3NoQWZjmi3UCxd/QMn9R4nZY+HZ9NVXJldlqdlKYdRMLiYVBhJV1nwBuA
OGytc1ty8qzk4yBqVz0J3yHqefpUzfhivoMMeJRVjztdMInaH3Tn4Gn2HPM1/YTr
A4SL9I1TG/Nocpo4kUZ/tObbZxTOuQ6g+wKaWHY/O2bc8k/XI2woXbB6IxpvXZyS
YvWHz2uQmbRco1TN4FVWl7aAvL+aGBxt/+07S2AhI0ftQIlmVAVrJmsJ09o+3c5Z
j1uRrjrM7R3bAWw8R369tJ10Khyx+nqCbW4aAwxKs+g=
=MaJH
-END PGP SIGNATURE-

php-7.2.30.tar.xz
SHA256 hash:
aa93df27b58a45d6c9800ac813245dfdca03490a918ebe515b3a70189b1bf8c3
PGP signature:
-BEGIN PGP SIGNATURE-

iQItBAABCAAXBQJeldtkEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXKSMw/+
KnqtOK/cRciKXJj5yr+AjjmNV7N0dh7y9WBdsygKuHE+wkg1xW71tx5SdI9YaCNX
VVodYz7Uu4vVoIEYnkCylzPG5MUYCN4BMl/LoXLs162Zq0BUhhoGu//VMOKECD2n
che/jqRKfhpBgQoCy0+HQuF2xY7yOxiGiMJiXSrYwgMroqb+jDNJPe3m7ajXurmO
DTDbX4tRra0V8r51TIyEMpvOP7bqQNmtQWqyRx/f4iJ7aaljp/nKEmTX6AWvpjTD
Pd36zNU2NKT/uLHtN80p5miGfqUgbA50p+S0/nvKarniW05++LfGqg15xoWF76/E
Nah0gwTTXm8T6bChO1goSccVUz6GaihVd6vbcJEQgobkg0bPgKmCdAgMdS6LISH+
aIGO2NkM2Aw///Q823vqCOno9dqOHkjrRPi+FxlEEaQK4BpCm1wyqt2+7EteFQaa
WtdkdzmM49QYSw62z/66S/ylYu2vddwF2TYXUuSo6/OVhVI+PhOoLtEyHUqEf82Q
fEXas8ZKL7LZMpv6GdbSGs8f3nVRsAu+mPK4Nhuyxi6jHRMGwHX+A4Udp91UhZW9
bzoxV+To4NOGjSlPTSwVZarUi3yhPs9QvtPAX4oO5mevWCMA+Gs9kRD/mA3ZkjQe
fUw2TItg52jVcnzpftvHtaI+pyrGmXaKH4qggC3wEsU=
=9iTq
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] Mixed type

[Sara Golemon]

On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield 
wrote:

> On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote:
> > Here is an RFC for adding a 'mixed' type to the language:
> > https://wiki.php.net/rfc/mixed_type_v2
> >
>
> I am not against this, but now that we have Union types what places are
> there where the currently available type declarations are insufficient?
> Resource seems like the only remaining gap where you'd be forced to use
> `mixed` instead of a union.
>
> I imagine some type combinations get pretty wide. Like, this is verbose AF.

null|bool|int|float|string|array|object|resource

For the long term good of the language I'd prefer type aliases (or typedefs
or usings or whatever you want to call them.

use mixed = null|bool|int|float|string|array|object|resource;
use scalar = null|bool|int|float|string;
use number = int|float;

That said, baking 'mixed' in as an implicit alias of the above isn't
problematic for that future.

-Sara

Re: [PHP-DEV] [RFC] Function pipe operator

[Sara Golemon]

On Mon, Apr 20, 2020 at 9:39 PM Ben Ramsey  wrote:

> > On Apr 20, 2020, at 20:38, Larry Garfield 
> wrote:
> >
> > I've been commenting on other RFCs enough lately that I should probably
> put myself through the wringer, too.  I therefore offer this RFC to add a
> function pipe operator, as seen in a number of other languages:
> >
> > https://wiki.php.net/rfc/pipe-operator-v2
> >
>
Happy with the revival, and I do want to underline the "Future Work"
section about Partial Functions.  PF will make this version of pipes 100%
more readable and fluent, and I want to endorse both, but I'll take one at
a time.

-Sara

[PHP-DEV] [8.0] 3-Month Reminder; Feature Freeze is July 28th

[Sara Golemon]

Per the current schedule ( https://wiki.php.net/todo/php80 ), PHP 8.0 is
set for feature freeze and branching on July 28th which is 3 calendar
months from today (13 weeks).

I would like to encourage everyone currently working on a proposal to
please plan on getting your RFCs into voting no later than June 16th (7
weeks from now, and 6 weeks from FF).  This will allow sufficient time for
a 2 week vote and provide a cushion for surprise delays.  Obviously, you
can run all the way up to the last minute by opening voting on July 14th,
and closing the vote/committing on the 28th, but I ask that you please
don't.  Take the time you have now to get your proposals in order.

8.0 is already packed with some fantastic goodness (
https://wiki.php.net/rfc#php_80 ) so if your RFC doesn't make the date,
that's okay.  8.1 will be one short year around the corner.

Thanks for your attention, and good luck on your RFC votes!
-Sara

Re: [PHP-DEV] Moving json extension to core?

[Sara Golemon]

On Wed, Apr 29, 2020 at 8:11 AM Nikita Popov  wrote:

> > Doing this would also make some extensions more convenient to use (e.g.
> > memcached with the json serializer, using json encoding for uses such as
> > error messages in miscellaneous extensions, etc.)
> >
>
> Another advantage would be that the JsonSerializable interface would be
> always available. This would make things simpler for extensions that want
> to hook into that. Currently we have a bunch of classes like DateTime,
> which do have custom JSON serialization behavior, but do not implement
> JsonSerializable, because the class is not always available.
>
> Technically, we could have these classes always implement the method and
only attach the interface conditionally during MINIT, but for sure the
mechanics become both simpler and more reliable for userspace scripts.
This gets a pretty easy +1 from me.  Looking at Ubuntu 20.04, they seem to
have json built-in to the core package anyway. I'm not sure about other
distros.


> > P.S. What are your thoughts about adding additional conversion specifiers
> > such as %j or %v to PHP to call JSON with the default options.
> > It's a feature similar to those I've seen in programming languages such
> as
> > golang - https://golang.org/pkg/fmt/#hdr-Printing
> >
> > - `printf("console.log("value from php", %j);\n", $value)`
> > - `printf("Some command returned %j\n", $boolValue)`
> >
>
> Uh, dunno. Is it really common to want JSON inside printf? I see printf
> mostly as something used to output to console, not so much in a web / data
> interchange context.
>
> It's possible (with some elbow-grease to make the %j approach a bit more
efficient since one could stream the serializer straight to the output, but
if that's really desired, there are other more explicit ways to make it
happen.
Ignoring streaming efficiency, the only real gain is replacing `"%s",
json_encode($x)` with `"%j", $x` which is of questionable gain.

In terms of getting it passed, I'd focus on just the first part, making
JSON a "core" builtin.  Let the printf modifier be a separate RFC, or at
least a separate question.

-Sara

Re: [PHP-DEV] Moving json extension to core?

[Sara Golemon]

On Wed, Apr 29, 2020 at 5:36 PM Benjamin Morel 
wrote:

> I want my classes to implement JsonSerializable, but this means requiring
>> ext-json and bumping the library version.
>>
>
> At the risk of derailing... You can have your class implement the
interface unconditionally, then have a polyfill definition in your autoload
for cases where it doesn't exist.  Obviously, it won't have an impact on
calls to json_encode(), but if the interface doesn't exist it's because
json_encode() doesn't either, so that should be harmless. :D

-Sara

Re: [PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM

[Sara Golemon]

On Tue, May 5, 2020 at 12:19 PM Derick Rethans  wrote:

> the vote for the second release manager has been concluded. At a nail
> biting 18 vs 19, Gabriel Caruso is chosen! Congrats.
>
> Congratulations, Gabriel!

I assume you're already familiar with
https://github.com/php/php-src/blob/master/docs/release-process.md as our
official process documentation.

I'd also like to point you at https://github.com/sgolemon/php-release (prebuilt
on docerhub as sgolemon/php-release ).  It does a LOT of the work described
under "rolling a release" in an automated and easy to recreate fashion.  I
invite you to do a trial run making an "alpha0" and uploading it to
downloads.php.net/~gabrielcaruso (Derick or someone will reach out shortly
on setting up an account and how to reach that server).

Also, don't forget to add your GPG key to
https://github.com/php/web-php/blob/master/include/gpg-keys.inc

-Sara

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

[Sara Golemon]

On Tue, May 12, 2020 at 3:26 AM Nikita Popov  wrote:
> // WeakMap::getIterator(): Iterator
> ZEND_METHOD(WeakMap, getIterator)
> {
> if (zend_parse_parameters_none() == FAILURE) {
> return;
> }
> zend_create_internal_iterator_zval(return_value, ZEND_THIS);
> }
>
Given that the body of this method seems to usually (always?) be the same,
why not define it in InternalIterator and allow it to be inherited?

> There's some bikeshed potential here regarding the class name.
>
Not personally over-picky, but I do agree that "Internal*" is a bit
awkward.  Unfortunately there's not much that's better and appropriate for
exposing to scripts.  This might be one of those rare occasions where
exposing "Zend" into userspace makes sense.  "PHP" is overloaded into
several meanings that are significant for userspace developers, but
something like "ZendIterator" might convey the right level of "This has to
do with the engine, please move along".  Or maybe go verbose:
'IteratorForExtensionClassImplementations'. :p

> ZEND_ASSERT(scope->get_iterator != zend_user_it_get_new_iterator); >
Does this mean that if I do `class Foo implements InternalIterator {}` in a
script, I can assert (crash) PHP? I don't see anything obvious (at a
glance) preventing me from inheriting from InternalIterator.

-Sara

Re: [PHP-DEV] Refactoring run-tests.php

[Sara Golemon]

On Fri, Jun 5, 2020 at 10:42 AM Max Semenik  wrote:

> I was thinking about making some improvements to our venerable test runner,
> however I wasn't feeling confident about improving the present code base.
> Instead, I decided to attempt to refactor it.
>
> This is a perennial topic and I don't want to discourage you,BUT...
run-tests.php has a disturbing number of modes and edgecases, and the
preference has traditionally been for small movements which are easily
understandable individually.  That's not to say a full-refactor won't get
support, but it's a big undertaking and has defeated many brave souls.

-Sara

[PHP-DEV] 8.0 release dates

[Sara Golemon]

TL;DR - Good news everyone! You have an extra week before feature freeze,
and GA is coming earlier than expected!

As alpha1 approaches, I was reviewing the scheduled release dates for 8.0
and noticed that we were offset from the active branch releases by 1 week.
In the interest of keeping releases aligned, and in consultation with my
co-release manager Gabriel as well as other RMs, I've decided to postpone
alpha1 by a week, meaning that alpha2 will coincide with the release of
7.4.8 and 7.3.20.  We'll also be removing RC6 (we have a LOT of
pre-releases after all) such that 8.0.0 GA will align with the release of
7.4.13 and 7.3.25.

The upshot, as stated in the TL;DR above is that folks trying to get
last-minute features into the language/runtime have an extra week before
feature freeze (previously Jul 28th, now Aug 4th), and users should expect
8.0.0-final a week earlier (previously Dec 3rd, now Nov 26th).

Obviously, this schedule is still subject to change if we find problems
during the pre-release which warrant additional time.

You may find the revised schedule at https://wiki.php.net/todo/php80

-Sara Golemon

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Sara Golemon]

On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch 
wrote:

> OMG the trolling continues even today with this nonsense. Disappointing.
>

Oh yes. And histrionics will certainly deescalate that issue.


> "...yes, it is broken, people have to Google or ask around for a very
> unclear error message when for the most part errors are (and should be)
> self explanatory
>

You know what shows up unambiguously in a google search? "Paamayim
Nekudotayim".
You know what ISN'T unambiguous in a google search? "Double Colon"
You know who don't have an excuse to say "Google is hard"? Software
engineers.


> ...Two things are broken: Either the token is named badly, or the token
> names shouldn’t show up in error messages at all and be replaced with
> something a bit more friendly.
>

Token names shouldn't show up.  Everyone is agreeing with that statement.
Universally.  Let's fix that problem rather than create new ones by not
addressing the underlying issue.

Once again I plead for logic and sanity. At least have the courage to put
> it to a vote.
>
> Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.

-Sara

Re: [PHP-DEV] New functions `hash_serialize` and `hash_unserialize`?

[Sara Golemon]

On Thu, Jun 11, 2020 at 11:59 AM Eddie Kohler 
wrote:

> Thanks for this suggestion. I've updated the implementation to make
> HashContext implement Serializable.
>
> I'd still be grateful for more feedback, or perhaps I should just create
> an RFC?
>
> Be careful what you ask for. :)

Overall +1 on the concept with a few notes:

1. Please put this on a branch and make it a PR so we can comment on it
directly.
2. Consider using zend_parse_parameters_throws() and family so that the
exception which is thrown contains the type error information rather than
the generic RETURN_THROWS() macros.
3. Consider using hex or base64 to serialize the contexts.  This will
reduce various transport/storage issues.
4. It's great that you've thought about endianness, but the current
implementation simply bails on endian mismatch. It'd be a nice-to-have for
the user if these serializations were portable.  I know this represents a
lot of work for sort of an edge case so I won't hold it against you if you
say 'no' and/or save this for later work if demand surfaces.
5. Storing $key makes me nervous.  I don't have a good solution to this
since the deserialization doesn't actually give us a chance to specify it
in the deserialization process.  I wish I'd made $key/hmac an option to
hash_final rather than hash_init.  Maybe we can think about allowing that
to be specified at either end.  Let's expand on this topic while you work
on your RFC.
6. Yeah... I think you need an RFC because of #5. Sorry.
7. TABS v SPACES indentation issues.

-Sara

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Sara Golemon]

On Mon, Jun 15, 2020 at 4:41 PM Deleu  wrote:

> As white men, we're being dismissive, insensitive and strongly suggesting
> we don't want change. While people may not feel offended by any of these
> terms being discussed, this thread alone already serves as reason for
> people to feel like there's no room for diversity in the internal community
> of php.
>

This.   We are (by and large) an awfully pasty group to be saying "This
isn't a real problem" and dismissing it out of hand.

A white person saying, "These words aren't problematic" is like responding
on bugs.php.net with "It works on my machine".


> I believe that if we cannot come together to take the small (potentially
> insignificant) step towards making changes that signal a welcoming
> environment, how are we going to actually take the big steps?
>
> OP initially came to Gabriel and I (as 8.0 RMs) to judge our response on a
small scale.  My answer was essentially "That's not my call, take it to
internals@" which he did, and frankly I'm disappointed by the reaction he
got.  I'm not saying this HAS to happen, or even necessarily SHOULD.  I
really don't know if these words are a problem or not because I'M NOT
QUALIFIED to answer that question.  I really wish we'd had a better
discussion than what we've started with though.

As to BC; You know I hate BC breaks for academic reasons, and (at the
moment) this certainly feels like a BC break for academic reasons, but
again... Don't know how abstract the problem is, just offering my pasty
hot-take.  It also doesn't have to be a violent BC break.  We can alias new
names to old and have a nice leisurely migration path on the way to 9.0 (or
even 10.0).

Last, regarding neutrality.  This proposal is literally aimed at adopting
more-neutral language.  It's not a partisan move to say that harmful
language should be avoided.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Sara Golemon]

On Wed, Jun 17, 2020 at 7:23 PM Ben Ramsey  wrote:

> I don’t understand this question:
>
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
>
> I recommended this as a front-line question so as to remove any hint of
impropriety about the vote.  For example, where the first round of the
secondary vote sits right now (15/15/4) we only have 44% in favor of any
specific change.  That doesn't nearly meet the 2/3rd requirement.  By
having a "pre-vote" to agree on reselecting the syntax, we have a CLEAR
2/3rd majority saying, "Yes, let's revisit this specific question again".

With that clarified, making the decision on what specific syntax we want is
less contentious.  I had *hoped* that we wouldn't have a party split on the
primary vote, that people who wanted <<>> would still favor a
reconfirmation of the syntax since it was specifically cited that this
would be a point to come back to, but atm that's how things turned out.

Is this a vote to see if we want to re-vote on the attribute syntax? I
> think this is worded awkwardly, and I’m not sure what the outcome of a
> yes or not vote means for this question.
>
> Yeah, the wording is awkward, but so is the situation. /shrug
I hope the above clarifies it.


> If I vote “no,” should I still vote in the secondary vote, or is voting
> “no” effectively the same as choosing `<<>>` for all three choices in
> the secondary vote?
>
> On the primary, you should vote yes if you believe it's worth revisiting
the topic, or no if you feel the people have spoken and alligator syntax
means alligator syntax.
Regardless of primary vote: You should vote on the secondary according to
your preference of syntaxes.

-Sara

[PHP-DEV] PHP 8.0.0alpha1 is ready for testing

[Sara Golemon]

PHP 8.0.0alpha1 has just been released and can be downloaded from:
https://downloads.php.net/~pollita
Or use the git tag: php-8.0.0alpha1

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

This is the first official release of the PHP 8 serial and includes an
incredible amount of work.
Please test it carefully, and report any bugs at https://bugs.php.net

8.0.0alpha2 should be expected in 2 weeks, i.e. on 9 Jul 2020.
Hash values and PGP signatures can be found below or at
https://gist.github.com/sgolemon/9b268eb2606cdc9664d77a77f9595540

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

php-8.0.0alpha1.tar.gz
SHA256 hash:
dbc1df78f4b4bf758d796c0265b05500ab5e8d501543c5d7f42aeb67c9bbaa13
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLMQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgXhEACHhj72vnMzXA5hHHCqP9OHO68kIpsf7M3Z
T+FnAH0YcsCBwo3F7DYE46+gp6bbY8+L0glJYGqJ/ff+WpMX6bE8OzWwOZsfhn7j
pn4LC7FElO75He2CtJR03Mgta3ZTrK3eRyDqr8PFbCF4Gcywlbk/BNuGmERLYwqE
jgR/oEd5ExiF/R/5aWEviThZv5WkNGzVwd4m5pd7PKw0b5C5ujTlYbOB8JboSuOC
AOvfOV/jTjPfOQa4+aSNTPTcksJ6DcHOHjgDqurvjBs0PxH16aNDA0cesT9TYbw1
L16Bm/cpLXXJLT5Alpn+NzwwlZVR87p5AYGlzPTUfyDEM+NkJbw+84lF8o4ZokTb
mAJewjaQoKkKcU9zakz5FyGIpvbthawB2zW3IS/KAI8kqHsjoxVhCNtuWhH/6D4A
Zx6fGJR54gF8n3Zdm2pDKzki5fyTssC078loH1G0VcW1cPavPFSjRvc3chgurnGF
VTk+33nWQiOjDhXgD4F5PXP+g6eaWSz1jHjtO5yON2rMpd8Id63KFkV/tpu7CfAI
JLIYNu52YnNgntZhEHvJrhQEr71F+qMAMb1HMCSUO4f4Goofc+PudbsMs6wWmTBc
D7QZvKARBuAQfqAecUDOMh7zlE+Tdolph8X8TOWwSdmf8lVvN17c0vMoukzg6Zrk
1fhq2RZeqA==
=iL1M
-END PGP SIGNATURE-

php-8.0.0alpha1.tar.bz2
SHA256 hash:
06fb3beb67176a0e096cb7e89368aa2a0063c0a963bc69dad862895e2474f4ee
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgwND/9lUGNPQ333g0EXyisVd3ddYN04+fmSyIG6
3nWS4xvph7VYGBzHqbyxmriHC9GPWcF1dBbD24fXzxxCpOy46vmwdJ27n0sHtdDf
7U5ViK0JCe8w7rehO01D0ZuQHERxsOllCg03uur7fHjy6m5VZq73NI+/LxX8uDI6
WCNh5PSjpkgOWtTShlkcD/OUWiynXajsjemIb0pNPYn/zIPSP1IYiJn8ZsewBIjQ
fKFqvvkOEMAzADlzAtBOvdQAno9UnbJAvQ1QzP6DlD5S7IZDRhuqm/92hJcYBVel
Wtwr/oAqPJsj6azsC0O5tA2c4vgkh8xpLKKX55e46k0dB6KZH8JWrz8zyMPN5NQN
xeGy0P883xeZZBG7HoRCLbxxSZm8GtnlxHGdLMtf9h9Rtz0fk2GHcJdAqYz6XlIj
mDDBiWf99xm6ANeC9dbfdebNzr5E8vZF4WYBAPN8I5KMH2vMv35QZSbncnnyDwBf
CHJAac3b8bwi8kR4QZd4N9/BrnBkiMxA+B2AFb1L0aXvamVZiX/bryse2NVmqyyr
yP4jZGHiq8reNinYvBI/m4f58bt8X7mFhSBjHWVcoZpCaWH/UXg5nVwbS1aKe0SP
ahypoxiOo/N89jY3xoF0MPMseQlSvgx6+aQq9sYrDuPDpJRSvlRQ1kxH4UQQ7lFf
zJEUOLDDag==
=p6DW
-END PGP SIGNATURE-

php-8.0.0alpha1.tar.xz
SHA256 hash:
2ab527b3b96908b123271ee390ea01169effeb5027a7f85dbe4d0d37d7da1628
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhct7wD/9qvy4ZTIHegEIqBzJrUSHgTy4uFSu5onED
XP7BTeCmftE7eXN4XNE4YZlGsPt+sTaGNuTXygued84c7cr+panT6bg52261h5I4
6A6SQr5Xb8MGcoCxZ/V7h/64AGRi3bRZNyS43JjksHLwuW1gt3tH2vKMbccHc7OH
ON2H4gkdgKx1a5fKX9HH1QCTorIvGQq3mgvQMwTJ+yQaQMHd8OOUMmTN6fycVsg9
wCdA+ld0tSDa47lkMVIsqeyjNSup98OvOz7r4ctiVgwbU7HSGhPxgW+k0TcvpEgc
W1stWg+6c+YHJXIP8cH+Fn4ClCkIDJnvmeT+1MaCAhMZfvCScwGG25h50235mMRn
kvTaBRVT6uZpCUR+6HQ149gsvymJIuJDVHEqMAW7Q9s+gyvYpNhfbZ+RUUA6z2ck
CzMukaEJcFYHpZiRyG7TNrTY29DgKXE0rVZ1S2o4LLbTYzLHm5weEa1nVXFIs7H2
qT9GkH1APTAzGk7sYwxK3sx6MJqvlWYnaWjbAO7QiaVdMGXPQI1d1n6yqFVEYMKR
BxHu0p4Sm0SEsT0Isw7Alz/h1ptm8qwci72cmw+npUdFaeDdF6aQu1riR8v1olhU
5PZVjtF4FhJH2eiOy49DV7W2uSDvNw/MXu80sySWfznJFRXcqLppn/5dH3moN76V
g356aZ68EQ==
=0dr0
-END PGP SIGNATURE-

[PHP-DEV] [VOTE] IntlTimeZone::getWindowsID() and getIDForWindowsID()

[Sara Golemon]

Opening vote on
https://wiki.php.net/rfc/intl.timezone.get-windows-id#vote at
2016-04-01 01:37 UTC.
Vote will close in two weeks: 2016-04-15 23:59 UTC

-Sara

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

Re: [PHP-DEV] Copy On Write and Assign By Reference perform different on PHP5 and PHP7

[Sara Golemon]

On Thu, Mar 31, 2016 at 9:47 AM, Huqiu Liao  wrote:
> I have a question about Assign By Reference and I posted on StackOverflow,
> I'd like to know the reason behind it, and I did not get any this kind of
> answer, can anyone give me some clues.
>
Are you asking out of curiosity? Or because you think a new bug has
been introduced in PHP7?

If the latter, I'd respond by pointing out that the behavior of using
multiple operations with side-effects (like pre/post inc/dec) is
defined as undefined.  That is, while the PHP reference implementation
may give you a particular result, you should not rely on that result.

If the former, and you're just curious why, it comes down to a very
fundamental change in the way PHP7 deals with references.  I'd
recommend reading Nikita's writeup of the differences between PHP 5
and PHP 7 variables at:
https://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html

-Sara

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

Re: [PHP-DEV] [VOTE] IntlTimeZone::getWindowsID() and getIDForWindowsID()

[Sara Golemon]

On Mon, Apr 4, 2016 at 2:52 AM, Derick Rethans  wrote:
>> https://wiki.php.net/rfc/intl.timezone.get-windows-id#vote at
>
> I think the RFC misses that either mapping might not work, and hence can
> not always return a string. The code handles it correctly by returning
> false though. Make sure this ends up in the documentation though :-)
>
Fair point.  I revised the text of the RFC to reflect returning FALSE
on failure.

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

[PHP-DEV] IntlCharsetDetector

[Sara Golemon]

The subject of character set detection (yes, I know, a hard problem to
solve) came up on SO chat, and Niki noticed that we don't yet wrap the
ICU UCharsetDetector API so I volunteered to put something together.

https://github.com/php/php-src/compare/master...sgolemon:intl.charsetdetector

The trouble is, for the WIDE majority of my test cases so far, ICU is
really bad at detecting character sets correctly (as I said, it's a
tough problem).  In fact, the ICU manual admits that it doesn't even
look at all of the corpus text, and the "language detection" is a
byproduct not meant for actual language detection.

Given all that, I'm inclined to reject the idea of rolling this into
PHP for fear of just confusing users without actually adding any
value.

Thoughts?

-Sara

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