On Fri, 19 May 2023, Jorg Sowa wrote:
> I would like to propose the deprecation of the constants DATE_ISO8601,
> DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.
…
> In my opinion the question is not whether this constant should be
> deprecated, but when. I know that the
On 15 May 2023 13:38:56 GMT-05:00, Larry Garfield
wrote:
>On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote:
>> On 15 May 2023 09:54:41 BST, "G. P. B." wrote:
>>
>>>Why are we assuming that PHP 9.0 is going to come after PHP 8.4?
>>
>> Historically, PHP has had a major release roughly every
On Thu, 27 Apr 2023, Máté Kocsis wrote:
> As you have possibly already experienced, overloaded signatures cause
> various smaller and bigger issues, while the concept is not natively
> supported by PHP. That's why I drafted an RFC which intends to phase
> out the majority of overloaded
On Mon, 24 Apr 2023, Daniil Gentili wrote:
> I've submitted https://github.com/php/php-src/pull/11126 to add
> support for final anonymous classes, though as noted by iluuu1994, it
> would probably make more sense to just make all anonymous classes
> final by default, what do you think?
Yes.
On Thu, 20 Apr 2023, Larry Garfield wrote:
> Before we dig into any of those edge cases, however, we want to throw
> the question out: Is this general approach even acceptable?
I think I would vote against all three options. It is hard to put a
pulse on, but IMO it looks too complex. I'd say:
On Wed, 26 Apr 2023, Alexander Pravdin wrote:
> A `decimal` builtin scalar type with some predefined precision
> (probably configured in php.ini). I can set the precision explicitly
> like `decimal(10,4)`.
Introducing a real decimal type is not an easy feat. First of all, we
would probably need
On Mon, 17 Apr 2023, Máté Kocsis wrote:
> Hi Everyone,
>
> Quite some time after mentioning the "clone with" construct the first time
> (at the end of the
> https://wiki.php.net/rfc/write_once_properties#run-time_behaviour section),
> finally I managed to create a working implementation for this
On Mon, 10 Apr 2023, G. P. B. wrote:
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
>
On Mon, 27 Mar 2023, G. P. B. wrote:
> While working on analysing the impact of the changes proposed by
> amending the behaviour of the increment and decrement operators (
> https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that
> the range() function has some rather lax behaviour
On 12 April 2023 19:05:56 BST, tag Knife wrote:
>On Wed, 12 Apr 2023 at 19:00, Reinis Rozitis wrote:
>
>>
>> Sadly, there isn't anything useful being discussed just some people being
>> upset about why someone doesn't (immediately) want to move to their
>> [favorite] platform what gives even
On 12 April 2023 14:52:52 BST, Alex Wells wrote:
>What are your thoughts?
Not a chance. Also, who are you?
cheers
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 11 April 2023 14:33:27 BST, Jeffrey Dafoe wrote:
>> was something introduced in a time that the code being written using it has
>> 100% test coverage and static analysers protecting it. It's easier for me to
>> deal
>> with any BC breaks of PHP 7.1 or higher than it is to deal with
On 30 March 2023 14:56:55 BST, Larry Garfield wrote:
>On Thu, Mar 30, 2023, at 9:25 AM, Christian Schneider wrote:
>> Am 30.03.2023 um 10:50 schrieb Lynn :
>
>
>>> , and most importantly you have to remind yourself.every time to press
>>> "reply all".
>>
>> As it is sufficient to just reply to
On 28 February 2023 21:04:35 GMT, Max Kellermann wrote:
>On 2023/02/28 21:16, Dmitry Stogov wrote:
>> Recently we voted for inluce cleanup RFC
>> https://wiki.php.net/rfc/include_cleanup and it was declined.
>> Despite that a series of code refactoring commits from Max were silently
>> merged
On 15 February 2023 15:18:31 GMT, Max Kellermann wrote:
>On 2023/02/01 13:13, Max Kellermann wrote:
>> Voting starts now, please vote on my RFC:
>> https://wiki.php.net/rfc/include_cleanup
>
>Hi,
>
>voting of https://wiki.php.net/rfc/include_cleanup has ended today at
>15 UTC.
>
>The majority
On 15 February 2023 13:03:39 GMT, Lydia de Jongh wrote:
>Hi,
>Very interesting topic! On which I have NO experience
>
>
>
>Op wo 15 feb. 2023 om 08:02 schreef Rowan Tommins :
>
>> On 15 February 2023 05:18:50 GMT, Rowan Tommins
>> wrote:
>> >My instinct was that it could just be a built-in
On 13 February 2023 08:28:50 GMT, Derick Rethans wrote:
>On 13 February 2023 04:48:16 GMT, Stanislav Malyshev
>wrote:
>>Hi!
>>
>>Somebody have put a ton of garbage reports in bugs.php.net under security
>>bugs. Cleaning them up manually is kind of annoying, could
On 13 February 2023 04:48:16 GMT, Stanislav Malyshev
wrote:
>Hi!
>
>Somebody have put a ton of garbage reports in bugs.php.net under security
>bugs. Cleaning them up manually is kind of annoying, could somebody with DB
>access go in and clean them all up? They all have either OS or Summary
ood thing, even though it seems tedious at first.
This is a very naive view of the world. You don't get to decide what is
"good for other people".
> > Do you see any downsides to your new approach?
>
…
> Derick Rethans wrote my idea "adds nothing but clutter&qu
On Tue, 17 Jan 2023, G. P. B. wrote:
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++
> behave like $v += 1 and $v--
On Tue, 17 Jan 2023, Christian Schneider wrote:
> Am 17.01.2023 um 15:59 schrieb G. P. B. :
> >
> > I might be again misunderstanding, but one cannot extend an enum as
> > they are final classes under the hood. Currently, the only other
> > native enum is the one that was added with the
On Tue, 17 Jan 2023, G. P. B. wrote:
> I would like to start the discussion about the Saner
> array_(sum|product)() RFC:
> https://wiki.php.net/rfc/saner-array-sum-product
>
> Currently, the array_sum() and array_product() behave differently than
> their userland implementation as they ignore
On 9 January 2023 18:49:28 GMT, Sara Golemon wrote:
>I've been working with JWTs lately and that means working with Base64URL
>format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
>This is essentially the same thing as normal Base64, but instead of '+' and
>'/', it uses '-' and '_',
Hi!
While I was enjoying the fireworks, the RFC's vote closed with 25 in
favour, and one against. I will now be starting to work on the
implementation.
https://wiki.php.net/rfc/datetime-exceptions#voting
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
On Fri, 16 Dec 2022, Tim Düsterhus wrote:
> Hi
>
> On 12/16/22 14:55, Derick Rethans wrote:
> > > --
> > >
> > > getPositionOfFirstOccurrence():
> > >
> > > I agree this is too long. How abo
On Fri, 16 Dec 2022, Rowan Tommins wrote:
> On 16 December 2022 13:55:02 GMT, Derick Rethans wrote:
> >I do not want a polyfill. These already exist for intl and friends.
>
> I think you misunderstood what I meant by "polyfill"; I meant in the
> sense that once
On 16 December 2022 21:34:16 GMT, Theodore Brown wrote:
>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans wrote:
>
>> Hi,
>>
>> I've just opened the vote for "More Appropriate Date/Time Exceptions".
>> It runs until December 31st, 24:00 UTC.
>>
&
On Thu, 15 Dec 2022, Tim Düsterhus wrote:
> On 12/15/22 16:34, Derick Rethans wrote:
> > You can find it at:
> > https://wiki.php.net/rfc/unicode_text_processing
> >
> > I'm looking forwards to hearing your opinions, additions, and
> > suggestions — the RFC spec
On Thu, 15 Dec 2022, Rowan Tommins wrote:
> On 15/12/2022 15:34, Derick Rethans wrote:
> > I have just published an initial draft of the "Unicode Text Processing"
> > RFC, a proposal to have performant unicode text processing always
> > available to PHP users, by
On Fri, 16 Dec 2022, Tim Starling wrote:
> On 16/12/22 02:34, Derick Rethans wrote:
> >
> > I have just published an initial draft of the "Unicode Text
> > Processing" RFC, a proposal to have performant unicode text
> > processing always available to PHP u
On Thu, 15 Dec 2022, Daniel Wolfe wrote:
> On 2022-12-15 8:34 AM, Derick Rethans wrote:
> > Hi,
> >
> > I have just published an initial draft of the "Unicode Text Processing"
> > RFC, a proposal to have performant unicode text processing always
> > a
On Thu, 15 Dec 2022, Tim Düsterhus wrote:
> [1] The 'Text' class should likely be made final, because folks might
> otherwise rely on a specific userland extension, preventing actual
> interoperability.
Yes, I intended to do this, but forgot to include it. I've updated the
RFC.
cheers,
Derick
On Thu, 15 Dec 2022, Sara Golemon wrote:
> On Thu, Dec 15, 2022 at 9:34 AM Derick Rethans wrote:
>
> > I have just published an initial draft of the "Unicode Text
> > Processing" RFC, a proposal to have performant unicode text
> > processing always available
On Thu, 15 Dec 2022, Paul Crovella wrote:
> On 12/15/2022 7:34 AM, Derick Rethans wrote:
> > https://wiki.php.net/rfc/unicode_text_processing
>
> A few quick thoughts:
>
> > The constructor will also convert the given text to Unicode Canonical Form.
>
> By this do
On Thu, 15 Dec 2022, Jakub Zelenka wrote:
> On Thu, Dec 15, 2022 at 4:56 PM Christoph M. Becker
> wrote:
>
> > On 15.12.2022 at 16:34, Derick Rethans wrote:
> >
> > > I have just published an initial draft of the "Unicode Text
> > > Processing"
On Thu, 15 Dec 2022, Marco Pivetta wrote:
> On Thu, 15 Dec 2022 at 15:27, Derick Rethans wrote:
>
> > I've just opened the vote for "More Appropriate Date/Time
> > Exceptions". It runs until December 31st, 24:00 UTC.
> >
> > You can vote at:
> >
Hi,
I have just published an initial draft of the "Unicode Text Processing"
RFC, a proposal to have performant unicode text processing always
available to PHP users, by introducing a new "Text" class.
You can find it at:
https://wiki.php.net/rfc/unicode_text_processing
I'm looking forwards to
Hi,
I've just opened the vote for "More Appropriate Date/Time Exceptions".
It runs until December 31st, 24:00 UTC.
You can vote at:
https://wiki.php.net/rfc/datetime-exceptions#voting
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like
On Sat, 10 Dec 2022, Robert Landers wrote:
> On Fri, Dec 9, 2022 at 5:31 PM Tim Düsterhus wrote:
> >
> > On 12/9/22 17:17, Dan Ackroyd wrote:
> > >> If your data fails to
> > >> unserialize, the only safe option is to throw it away.
> > >
> > > Even given that, you probably want to investigate
On 13 December 2022 15:55:41 GMT, Thomas Hruska wrote:
>On 12/13/2022 7:15 AM, Derick Rethans wrote:
>> On Mon, 12 Dec 2022, Thomas Hruska wrote:
>>
>>> On 12/12/2022 3:52 PM, Derick Rethans wrote:
>>>> On 12 December 2022 22:20:27 GMT, Dan Liebner wro
On Mon, 12 Dec 2022, Thomas Hruska wrote:
> On 12/12/2022 3:52 PM, Derick Rethans wrote:
> > On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> >
> > > It has been proposed to make the error level of "Undefined index"
> > > configurable so that
On Mon, 12 Dec 2022, Rowan Tommins wrote:
> On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> >Here's my biggest criticism: the change essentially forces this:
> >$arr['key']
> >
> >to be rewritten as this (or some other intolerably bad alternative):
> >isset($arr) && isset($arr['key']) &&
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
>It has been proposed to make the error level of "Undefined index"
>configurable so that teams and individual developers can decide for
>themselves how they want this situation to be handled. Given that:
>
> - PHP has been treating this as
Hi,
Is there any other feedback, because otherwise I am just going to open
this for a vote next Tuesday.
cheers,
Derick
On Tue, 29 Nov 2022, Derick Rethans wrote:
> Hi,
>
> I have just published a new "More Appropriate Date/Time Exceptions" RFC
> to sort ou
On Mon, 28 Nov 2022, Paul Dragoonis wrote:
> On Mon, 28 Nov 2022, 16:32 Christoph M. Becker, wrote:
>
> > On 28.11.2022 at 16:50, Derick Rethans wrote:
> >
> > > On Thu, 24 Nov 2022, mickmackusa wrote:
> > >
> > >> Can anyone explain to me
On Mon, 21 Nov 2022, Derick Rethans wrote:
> On 21 November 2022 11:34:10 GMT, Vincent Langlet
> wrote:
> >
> >When using json_encode or json_decode with the `JSON_THROW_ON_ERROR`
> >flag, `JsonException` might be thrown.
> >
> >When using `new DateTime('foo
Hi,
I have just published a new "More Appropriate Date/Time Exceptions" RFC
to sort out the warnings, errors, and already existing exceptions and
errors. There are a few minor BC breaks, of course listed in the RFC.
It is published at https://wiki.php.net/rfc/datetime-exceptions
Comments?
On Fri, 21 Oct 2022, Mikhail Galanin via internals wrote:
> (4) Derrek Rethans suggested introducing a new function (e.g.
> php_format_date_ex) that
> takes care of usecs (see the thread on Github)
It's 'Derick' :-)
> Looking into the future, probably we would like to have this format
>
On Thu, 24 Nov 2022, mickmackusa wrote:
> Can anyone explain to me why it is desirable/beneficial for the DateTime
> class to store a warning that trailing characters were ignored while
> parsing a date/time string with the + symbol in createFromFormat()?
I have no idea why I decided that was a
On 21 November 2022 11:34:10 GMT, Vincent Langlet
wrote:
>Hi,
>
>When using json_encode or json_decode with the `JSON_THROW_ON_ERROR` flag,
>`JsonException` might be thrown.
>
>When using `new DateTime('foo')`, a generic `Exception` is thrown.
>Incidentally, I wonder why it's not an
On Mon, 14 Nov 2022, Ilija Tovilo wrote:
> Hi Derick
>
> > > As I understand it, you’re suggesting that a property declared as
> > > `public protected(set)` would never trigger __set().
> >
> > I would think that that would be against our current practice, which is
> > easy enough to explain as
On Mon, 14 Nov 2022, Stephen Reay wrote:
> As I understand it, you’re suggesting that a property declared as
> `public protected(set)` would never trigger __set().
I would think that that would be against our current practice, which is
easy enough to explain as "if the property isn't visible
On Sun, 13 Nov 2022, Larry Garfield wrote:
> There's two design decisions we've made at this point, both of which
> we think are logical and reasonable:
>
> 1. If specified, the set visibility must be tighter than the get
> visibility. So `protected protected(set)` and `protected public(set)`
load>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.33>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
P.S. Below is the verification information for the downloads, whi
On 25 October 2022 14:10:14 CEST, BohwaZ wrote:
>* but we make SQLite3 throw exceptions by default directly in PHP 8.3,
> like it was done with PDO 2 years ago.
I am not in favour, as it would mean that existing code suddenly may start
breaking, as exceptions aren't expected (and hence not
On 18 October 2022 02:26:59 BST, Tim Starling wrote:
> If I'm reading the implementation correctly, the original exception
> is thrown away, there's no way to get the
> original message and backtrace.
> That will make debugging more difficult.
I believe that is not true. It should be wrapped
Hi all,
On Sat, 1 Oct 2022, Kamil Tekiela wrote:
> For quite some time now, PHP's sanitize filters have "Rustled My
> Jimmies". These filters bother me because I can't really justify their
> existence. I can understand that a few of them are sensible and may
> come in handy, but I would like
On 29 September 2022 12:32:57 BST, Lynn wrote:
>On Thu, Sep 29, 2022 at 12:50 PM Yasuo Ohgaki wrote:
>
>> 2022年9月29日(木) 18:58 Derick Rethans :
>>
>> > The PHP development team announces the immediate availability of PHP
>> > 7.4.32.
>> >
>>
&
hangeLog-7.php#7.4.32>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
P.S. Below is the verification information for the downloads, which is
also available on
<https://gist.github.com/d3ec1820a6606dec9efb8
On 13 September 2022 19:36:15 BST, juan carlos morales
wrote:
>El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
>dev.juan.mora...@gmail.com> escribió:
>
>>
>>
>> El mar., 13 de septiembre de 2022 14:58, Mel Dafert
>> escribió:
>>
>>>
>>> In summary, I believe this can only be
On 4 September 2022 11:46:18 BST, Nicolas Grekas
wrote:
>Hi Marco,
>
>IMO good as-is: can be relaxed later (8.3 or later), if anybody believes
>> it's a show-stopper.
>>
>Readonly classes don't really need to be lazy.
>>
>
>"Break things and move slow" doesn't feel right to me for the language.
On 26 August 2022 18:28:59 BST, Kamil Tekiela wrote:
>What is the reasoning behind the name? I can't find it explained in the
>RFC. What about other alternatives like is_json or validate_json?
It's part of the json extension so it should start with json_ following naming
guidelines for
On 8 July 2022 16:24:13 CEST, Sara Golemon wrote:
>On Thu, Jul 7, 2022 at 11:54 AM Christoph M. Becker
>wrote:
>> I wonder what we should do with qa.php.net.
>>
>
>I too have wondered this many a time.
>
>> The only really relevant stuff on the Website is the listing of
>> available QA releases,
On Mon, 4 Jul 2022, Christoph M. Becker wrote:
> On 04.07.2022 at 10:16, Remi Collet wrote:
>
> > In PHP 8.1:
> >
> > This branch is 1 commit ahead, 7 commits behind master.
> >
> >
> > This seems terribly wrong, looks like was merged from master
> > (NEWS file have 8.2 entries)
> >
> >
> > Can
On 21 June 2022 23:47:15 BST, Nicolas Grekas
wrote:
>Hi everyone!
>
>I'd like to open a discussion on this RFC, to auto-implement Stringable for
>string-backed enums:
>https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
>I'm looking forward to your feedback,
I am not in
On 22 June 2022 05:38:13 BST, Pierrick Charron wrote:
>Hi,
>
>Following our discussions we had on the subject of the new Curl URL API,
>and other curl improvements. I decided to only focus on adding the new Curl
>URL API and put aside all other improvements. Here is the RFC that reflects
>our
On 11 June 2022 08:13:15 CEST, Aaron Junker wrote:
>Hi all
>
>I will now open voting on my RFC for creating a global php.net login system[1].
I think this is not a good RFC, and very premature:
- It lists wants and promises, but no solutions. No work has been done to
investigate how to
;https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
P.S. Below is the verification information for the downloads, which is
also available on
<https://gist.github.com/d0cdf0570e19805af9fe931b1c15115c&
On 8 June 2022 20:22:46 BST, Aaron Junker wrote:
>Hi all,
>
>I've edited my RFC[1], so it now contains a note that edit.php.net is
>currently not in a usable state.
>
>Besides that, I didn't find any big points that could have been added to the
>RFC.
>
>So, unless a big new discussion starts, I
ation guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
P.S. Below is the verification information for the downloads, which is
also available on
<https://gist.github.com/166cb2218ad0f28d077ce58f8804e2f9&
On Thu, 7 Apr 2022, Nikita Popov wrote:
> On Thu, Apr 7, 2022 at 11:34 AM Derick Rethans wrote:
>
> > Java's date/time maintainer has created a fork based on the original
> > Iana TZ data to put back some of the removed/deprecated data to
> > better serve their
Hi!
As you might be aware, I maintain the date time support in PHP. As part
of that I regularly have to update the rules that timezones employ -
changes in Daylight Saving Time rules, or other changes to rules due to
political foibles.
In the last few years, the maintainer of the Iana TZ
On 31 March 2022 16:45:29 BST, Ilija Tovilo wrote:
>To avoid disruption, I'm proposing to merge this into PHP 8.2 only.
>Unless anybody has any objections to this change I will merge it in a
>few weeks.
As original author of var_export, I believe this is good to merge, but for PHP
8.2+ only.
On 15 March 2022 15:41:45 GMT, "Côme Chilliet" wrote:
>Le samedi 12 mars 2022, 19:30:00 CET G. P. B. a écrit :
>> true is not a type in PHP compared to false, therefore it is not included.
>> I'm working on a proposal to add true as a type to PHP, but that's a
>> seperate RFC and discussion.
>
On Wed, 2 Mar 2022, naitsi...@e.mail.de wrote:
> I only wanted to make clear, that if we start to support Ukraine as
> the victimized party in this conflict we have to do that in other
> conflicts, too.
This is a logical fallacy called whataboutery, and an invention of the
Soviet Union
w.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.28>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
Hi!
In the last few days I have been investigating Xdebug bug #2051:
"Segfault on fatal error when setting xdebug.mode via php-fpm pool
config" (https://bugs.xdebug.org/view.php?id=2051).
I have now tracked this down to an unexpectedness in how PHP-FPM handles
extension/module initialisation.
ation guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Derick Rethans
P.S. Below is the verification information for the downloads, which is
also available on
<https://gist.github.com/5c47726c9db4b49e7b4eb1781b36d229&
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<https://gist.github.com/derickr/d310d0ea45d6e23950952855f9bc744b>.
7.4.27 should be expected in 2 weeks, i.e. on December 16th, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
<https://www.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.26>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporter
Dear Internals,
On Wed, 10 Nov 2021, Nikita Popov wrote:
> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
>
> > This RFC takes the more direct route of deprecating this
> > functionality entirely. I expect that this will have relatively
> > little impact on modern code (e.g. in Symfony
Dear Internals,
I think it is a mistake to decide on a whim to move over to GitHub
issues without having evaluated anything else.
GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned
On 12 November 2021 13:07:42 GMT, Nikita Popov wrote:
>Hi internals,
>
>I've opened the vote on
>https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
>2021-11-26.
I've voted no on this one. Not because I don't like the idea, but because I
think the timeline for deprecation
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<https://gist.github.com/45491ec790d2324f6d7fe522e4a794ab>.
7.4.26 should be expected in 2 weeks, i.e. on November 18th, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
<https://www.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.25>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporters!
Deric
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<https://gist.github.com/f9bf1c8a217f00ffd78488759b1cf106>.
7.4.25 should be expected in 2 weeks, i.e. on October 21st, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
<https://www.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.24>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporter
/+el9LL4tYAXkX2Ob7HJQV7c00wj54EsmO4rybMaEfqESd/DH/qP
C7PAGVzQgVkSUaDePmr9FP6mDotAnhmljgJDH4H87LEptGZ45lIucARJLW8ekM1M
FDXruBVlcagl0Q2jhcMPV6iWClHYHHJMwJLAH/aAqQO18DjNRsL6S9nTE6ZIVDBN
IDreEm0ygyS3b/txx3fysYU6K2LusWA2XiKM5hh4/vcBHSZmx/E=
=UJdn
-END PGP SIGNATURE-
On Thu, 9 Sep 2021, Derick Rethans
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<https://gist.github.com/0c59c2edaa532b0f987f1ae3bb2aee1b>.
7.4.24 should be expected in 2 weeks, i.e. on September 23rd, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
Hi Dmitry,
On Mon, 30 Aug 2021, Dmitry Stogov wrote:
> Please, let me know you decision according
> https://github.com/derickr/timelib/pull/99
>
> This workaround fix makes ~170 times improvement on "new DateTimeZone()"
> and as result visible improvement on some real-life apps (e.g Symfony
<https://www.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.23>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporter
On 25 August 2021 17:58:55 BST, Nicolas Grekas
wrote:
>Le mar. 24 août 2021 à 21:09, Derick Rethans a écrit :
>
>> On 24 August 2021 19:53:57 BST, Deleu wrote:
>> >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote:
>> >
>> >> On Mon, 23 Aug 2021,
On 25 August 2021 18:34:18 BST, Nicolas Grekas
wrote:
>Le mer. 25 août 2021 à 19:32, Marco Pivetta a écrit :
,
>
>> On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas <
>> nicolas.grekas+...@gmail.com> wrote:
>>
>>> I would welcome a new RFC to clarify what is allowed during the feature
>>> freeze.
On 24 August 2021 19:53:57 BST, Deleu wrote:
>On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote:
>
>> On Mon, 23 Aug 2021, Deleu wrote:
>>
>> > We recently had the Nullable Intersection Types RFC process in an
>> > unconventional way starting a new RFC post f
On Mon, 23 Aug 2021, Deleu wrote:
> In order to not be empty-handed, I started a gist that can be seen as
> the starting point for this discussion, available at
> https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105.
4. A Refinement RFC MAY be proposed with a schedule for ending
On Mon, 23 Aug 2021, Deleu wrote:
> We recently had the Nullable Intersection Types RFC process in an
> unconventional way starting a new RFC post feature freeze. If memory
> serves me right, another similar incident happened with the Attributes
> RFC which had a syntax that could not be
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<https://gist.github.com/963d7c2847b22afbf19eb7b1b68117a8>.
7.4.23 should be expected in 2 weeks, i.e. on August 26th, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
<https://www.php.net/downloads>
Windows downloads:<https://windows.php.net/download>
Changelog:<https://www.php.net/ChangeLog-7.php#7.4.22>
Migration guide: <https://www.php.net/manual/migration74.php>
Many thanks to all the contributors and supporter
On Fri, 23 Jul 2021, Nicolas Grekas wrote:
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as
> currently accepted are not nullable. This RFC proposes to make them
> so.
>
> I wrote everything down about the
://bugs.php.net>.
Hash values and PGP signatures can be found below or at
<>https://gist.github.com/80d0a3e00eb0f86cd93625f2cdf2834b.
7.4.22 should be expected in 2 weeks, i.e. on July 29th, 2021.
Thank you, and happy testing!
Regards,
Derick Rethans
php-7.4.
1 - 100 of 2505 matches
Mail list logo
