Everything

php

[RFC] [VOTE]ValueError Conversions for PHP 8.6

php.internals

Muhammed Arshid KV

182 days ago

Hi everyone,

This is to announce the opening of the vote for the *ValueError Conversions
RFC*.

RFC:  https://wiki.php.net/rfc/php86_valueerror_conversions
Discussion thread:  https://externals.io/message/130090

The vote will be open for 2 weeks (and a few hours), closing on March 17th
at midnight UTC.

Cheers,
Muhammed Arshid

Christian Schneider

182 days ago

Am 03.03.2026 um 09:37 schrieb Muhammed Arshid KV <arshidkv12@gmail.com>:

> This is to announce the opening of the vote for the ValueError Conversions RFC.
> RFC:  https://wiki.php.net/rfc/php86_valueerror_conversions
> Discussion thread:  https://externals.io/message/130090
> The vote will be open for 2 weeks (and a few hours), closing on March 17th at midnight UTC.

What happened to the E_WARNING phase which was mentioned in the discussion and is normally used for stuff like this?
Compare https://wiki.php.net/rfc/deprecations_php_8_6#backward_incompatible_changes

In the current form it is a "No" from me and I'd appreciate if we settle the "Exempt input type and value validation from BC Break policy" question first before side-stepping the previously used warning phase.

Regards,
- Chris

Tim Düsterhus

182 days ago

Hi

Am 2026-03-03 09:37, schrieb Muhammed Arshid KV:

> This is to announce the opening of the vote for the *ValueError
> Conversions
> RFC*.
>
> RFC:  https://wiki.php.net/rfc/php86_valueerror_conversions
> Discussion thread:  https://externals.io/message/130090
>
> The vote will be open for 2 weeks (and a few hours), closing on March
> 17th
> at midnight UTC.

There are no voting options available in the RFC for reasons that are
unclear to me. Looking at the page’s source code I don't see an obvious
mistake with regard to the markup for the voting doodle.

I'm however noting that the options do not include the “Abstain” option
that is required per our policy:
https://github.com/php/policies/blob/main/feature-proposals.rst#required-majority

I am also unable to find an “Intent to Vote” announcement for this RFC
in the mailing list archives and the corresponding discussion thread is
only 12 days old as of now (which is less than the cooldown period of 14
days after the initial proposal). As such the start of the vote is
violating our current policy in multiple points.

I also don't think that this RFC has properly been discussed and I don't
feel it is productive to individually vote on every case of properly
validating input parameters. This warrants a generic decision, such as
the one proposed by Gina in her “Exempt input type and value validation
from BC Break policy” RFC: https://news-web.php.net/php.internals/130221

Given the clear policy violation regarding the vote, I request the vote
be canceled. I would also recommend to withdraw the RFC in favor of
Gina’s - but that is your decision as the RFC author of course.

Best regards
Tim Düsterhus

Muhammed Arshid KV

182 days ago

Thank you for your feedback.

I have added an "Abstain" option as well.

*Bukka* also shared a suggestion regarding this RFC.
Please check the latest message here:
https://github.com/php/php-src/pull/20971#issuecomment-3923902448

On Tue, Mar 3, 2026 at 5:26 PM Tim Düsterhus <tim@bastelstu.be> wrote:

> Hi
>
> Am 2026-03-03 09:37, schrieb Muhammed Arshid KV:
> > This is to announce the opening of the vote for the *ValueError
> > Conversions
> > RFC*.
> >
> > RFC:  https://wiki.php.net/rfc/php86_valueerror_conversions
> > Discussion thread:  https://externals.io/message/130090
> >
> > The vote will be open for 2 weeks (and a few hours), closing on March
> > 17th
> > at midnight UTC.
>
> There are no voting options available in the RFC for reasons that are
> unclear to me. Looking at the page’s source code I don't see an obvious
> mistake with regard to the markup for the voting doodle.
>
> I'm however noting that the options do not include the “Abstain” option
> that is required per our policy:
>
> https://github.com/php/policies/blob/main/feature-proposals.rst#required-majority
>
> I am also unable to find an “Intent to Vote” announcement for this RFC
> in the mailing list archives and the corresponding discussion thread is
> only 12 days old as of now (which is less than the cooldown period of 14
> days after the initial proposal). As such the start of the vote is
> violating our current policy in multiple points.
>
> I also don't think that this RFC has properly been discussed and I don't
> feel it is productive to individually vote on every case of properly
> validating input parameters. This warrants a generic decision, such as
> the one proposed by Gina in her “Exempt input type and value validation
> from BC Break policy” RFC: https://news-web.php.net/php.internals/130221
>
> Given the clear policy violation regarding the vote, I request the vote
> be canceled. I would also recommend to withdraw the RFC in favor of
> Gina’s - but that is your decision as the RFC author of course.
>
> Best regards
> Tim Düsterhus

On Tue, Mar 3, 2026 at 5:26 PM Tim Düsterhus <tim@bastelstu.be> wrote:

Ilija Tovilo

182 days ago

Hi Muhammed

https://wiki.php.net/rfc/php86_valueerror_conversions

On Tue, Mar 3, 2026 at 1:34 PM Muhammed Arshid KV <arshidkv12@gmail.com> wrote:

>
>
> Thank you for your feedback.
>
> I have added an "Abstain" option as well.

The voting widgets are still broken. The vote is open but no options
are available. It looks like the indentation is off:

"  * Yes" is incorrect, there need to be three spaces before the
options, i.e. "   * Yes".

Ilija

Muhammed Arshid KV

182 days ago

Hi Ilija,

> The voting widgets are still broken. The vote is open but no options
> are available. It looks like the indentation is off:
>
> "  * Yes" is incorrect, there need to be three spaces before the
> options, i.e. "   * Yes".

Thanks for pointing that out. I've fixed the indentation, and the voting
options should now be visible.

Best regards,
Muhammed Arshid

Jakub Zelenka

180 days ago

Hi,

On Tue, Mar 3, 2026 at 1:37 PM Muhammed Arshid KV <arshidkv12@gmail.com>
wrote:

>
> Thank you for your feedback.
>
> I have added an "Abstain" option as well.
>
> *Bukka* also shared a suggestion regarding this RFC.
> Please check the latest message here:
> https://github.com/php/php-src/pull/20971#issuecomment-3923902448
>
>>
>>

As Tim noted, there has been several important voting rules not followed so
this voting is invalid. This is understandable as you are new here but you
need to stop the vote. Personally I would prefer this to get voted closer
to the alpha release so more  cases can be added. There is no urgency to
start voting now.

Kind regards,

Jakub

Muhammed Arshid KV

180 days ago

Hi

On Thu, Mar 5, 2026 at 1:32 PM Jakub Zelenka <bukka@php.net> wrote:

>
> As Tim noted, there has been several important voting rules not followed
> so this voting is invalid. This is understandable as you are new here but
> you need to stop the vote. Personally I would prefer this to get voted
> closer to the alpha release so more  cases can be added. There is no
> urgency to start voting now.
>
>

Thank you
The vote is now closed.

Marco Pivetta

180 days ago

Hey Muhammed,

On Tue, 3 Mar 2026 at 09:38, Muhammed Arshid KV <arshidkv12@gmail.com>
wrote:

> Hi everyone,
>
> This is to announce the opening of the vote for the *ValueError
> Conversions RFC*.
>
> RFC:  https://wiki.php.net/rfc/php86_valueerror_conversions
> Discussion thread:  https://externals.io/message/130090
>
> The vote will be open for 2 weeks (and a few hours), closing on March 17th
> at midnight UTC.
>
> Cheers,
> Muhammed Arshid
>

I voted "yes" on most options except `error_log()`.

My rationale is that while hardening the filesystem-related functions you
noted in the RFC may highlight system issues, or even prevent security
issues, the `error_log()` function is everywhere in legacy code, and it
does not pose any risk if the parameters are misused (and silently ignored).

In fact, `error_log()` should not be used, but rather replaced by calls to
any PSR-3 compliant logger anyway.

Changing `error_log()` poses only burden on those that still have it in
their codebases.

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/