On 22 January 2024 10:21:12 GMT, tag Knife wrote:
>As you are mistaking `iint $var = null` params as "nullable". Which they
>are not, they are "optional default" parameters.
The feature which is being discussed is that, for the specific case of "=
null", the parameter is made both optional
On Mon, Jan 22, 2024 at 12:54 PM Larry Garfield
wrote:
> I am in support of this change. My only concern is timeline. This RFC
> would deprecate it in 8.4, and presumably support would be removed in 9.0.
> While we haven't discussed a timeline for 9.0, historically the pattern is
> every 5
On Mon, Jan 22, 2024, at 9:50 AM, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
>
> The only solution I can think of is to keep the deprecation in place
until PHP 10, but that's a very long time from now and the RFC says this
simplifies a decent amount of engine code, so I'm not wild about that idea.
Another solution is to have version 8.5. Also given the fact that much of
the
On Mon, Jan 22, 2024, at 1:48 AM, Gina P. Banyard wrote:
> Hello internals,
>
> I have updated the RFC to include a motivation and rejected ideas section:
> https://wiki.php.net/rfc/http-last-response-headers
>
> Unless there is further discussion, I intend to open the vote for the
> RFC on
On Mon, Jan 22, 2024, at 7:30 PM, Jorg Sowa wrote:
>> The only solution I can think of is to keep the deprecation in place
> until PHP 10, but that's a very long time from now and the RFC says this
> simplifies a decent amount of engine code, so I'm not wild about that idea.
>
> Another solution
On Mon, Jan 22, 2024, at 9:11 PM, Matthew Weier O'Phinney wrote:
> On Mon, Jan 22, 2024 at 12:54 PM Larry Garfield
> wrote:
>
>> I am in support of this change. My only concern is timeline. This RFC
>> would deprecate it in 8.4, and presumably support would be removed in 9.0.
>> While we
On 23-1-2024 3:18, Gina P. Banyard wrote:
The RFC notes that PHPStan and friends have an easy flag to make the change,
which is great, but still that's a minority of PHP devs that even know to use
static analysis.
One does not need to use a static analyser to determine or fix this issue,
On Monday, 22 January 2024 at 18:53, Larry Garfield
wrote:
> I am in support of this change. My only concern is timeline. This RFC would
> deprecate it in 8.4, and presumably support would be removed in 9.0. While we
> haven't discussed a timeline for 9.0, historically the pattern is every 5
On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
>
On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
>
I fully support this. I even wanted to propose this RFC myself. Implicitly
nullable parameters are extremely confusing in PHP 8 and they are very easy
to replace.
On Mon, Jan 22, 2024 at 11:21 AM tag Knife wrote:
> On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote:
>
> > Hello internals,
> >
> > Máté Kocsis and myself would like to propose deprecating implicitly
> > nullable parameter types.
> >
> > The RFC is available on the wiki at the following
Hi everyone
I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC.
https://wiki.php.net/rfc/rfc1867-non-post
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hello internals,
Máté Kocsis and myself would like to propose deprecating implicitly nullable
parameter types.
The RFC is available on the wiki at the following address:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime
On Mon, 22 Jan 2024 at 11:51, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
>
>
>
> I can absolutely give you write access to these pages. Updating this
> list to reflect more up-to-date resources certainly makes sense.
>
> As you probably know, there are a number of different places where php
> internals are documented, and I think that, long-term, it makes sense
> to try
Hi Jair!
On Mon, Jan 22, 2024 at 5:14 AM Jair Humberto wrote:
>
> My name is Jair Humberto, I am brazilian and have been working with PHP
> since 2006. I am super excited about the new things PHP has launched lately
> and finally realised that I can contribute as well. I think this is a new
>
On Fri, 5 Jan 2024, Derick Rethans wrote:
> I have just opened the voting on the "Policy Repository" RFC. It will
> run until January 22nd, 2024 at 08:00 UTC:
>
> https://wiki.php.net/rfc/policy-repository#voting_choices
Voting is now closed, and the RFC was accepted unanimously, with 28 for
Hi Carlos
You should now have access to the /internals sub-pages.
On Mon, Jan 22, 2024 at 11:38 AM Barel wrote:
>
> I didn't know that there was a list of tech resources listed in the
> "CONTRIBUTING.md" file. I have been researching resources that have
> information about PHP internals and
20 matches
Mail list logo
