Re: [PHP-DEV] [VOTE] Never parameters (v2)

Hey Daniel, I'm currently planning to vote "no" on this. The reason is that I see this RFC as very narrowly scoped on constructors / named constructors, and only in the case where a concrete class is referenced by a consumer. Constructors/named constructors are effectively not part of an object'

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

2025年4月17日(木) 16:16 Tim Düsterhus : > > Hi > > Am 2025-04-16 02:40, schrieb youkidearitai: > > The RFC for add grapheme_levenshtein function has been accepted. > > (Yes 12 / No 0) > > > > Thank you very much for voting. > > I will go to implementation. > > Great, thank you! I noticed that while you

Re: [PHP-DEV] [VOTE] PHP 8.5 Release Managers

Hi all, The polls have closed, and Derick’s scripts have tallied the votes [1], Our “rookie" PHP 8.5 release managers are: - Volker Dusch - Daniel Scherzer Our "veteran” is the PHP 8.2 & PHP 8.3 release manager Pierrick Charron, Volker and Daniel you are in a good hands! Further steps are desc

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

Hi Am 2025-04-16 02:40, schrieb youkidearitai: The RFC for add grapheme_levenshtein function has been accepted. (Yes 12 / No 0) Thank you very much for voting. I will go to implementation. Great, thank you! I noticed that while you updated the status in the RFC itself, you did not update the

Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

2025年4月1日(火) 13:39 youkidearitai : > > Hi, internals. > > I started vote to RFC grapheme_levenshtein > RFC: https://wiki.php.net/rfc/grapheme_levenshtein > > Voting end is 2025-04-16 00:00:00(UTC+0). > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh

Re: [PHP-DEV] [VOTE] Optional Interfaces

Hi Am 2025-03-20 17:09, schrieb Gina P. Banyard: And another user [2] was basically suggesting my previous solution of adding support for type classes/runtime implementation of interfaces. […] [2] https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhvxo5j/ I don't see how this could (usefu

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Saturday, 15 March 2025 at 09:23, Juris Evertovskis wrote: > On 2025-03-14 10:09, Juris Evertovskis wrote: > >> Hello, >> >> I’ve opened the vote on the Optional interfaces RFC. >> >> https://wiki.php.net/rfc/optional-interfaces >> >> Implementation: https://github.com/php/php-src/pull/17288 >

RE: [PHP-DEV] [VOTE] Optional Interfaces

Hello, The voting has concluded with 15 votes in favor and 19 against. As such, the RFC has been declined. https://wiki.php.net/rfc/optional-interfaces Thank you all for taking the time to consider the proposal and casting your votes. I'm especially grateful to those who helped refine t

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Fri, Mar 14, 2025 at 4:12 AM Juris Evertovskis wrote: > > Hello, > > > > I’ve opened the vote on the Optional interfaces RFC. > > > > https://wiki.php.net/rfc/optional-interfaces > > > > Implementation: https://github.com/php/php-src/pull/17288 > > Discussion: https://externals.io/message/12618

Re: [PHP-DEV] [VOTE] Optional Interfaces

On 3/14/25 03:09, Juris Evertovskis wrote: Hello, I've opened the vote on the Optional interfaces RFC. https://wiki.php.net/rfc/optional-interfaces Implementation: https://github.com/php/php-src/pull/17288 Discussion: https://externals.io/message/126185 The voting will be closed on 2025-03-2

Re: [PHP-DEV] [VOTE] Optional Interfaces

On 2025-03-20 18:09, Gina P. Banyard wrote: And another user [2] was basically suggesting my previous solution of adding support for type classes/runtime implementation of interfaces. Hey, There are two ideas -- the `$object implements Iface` that you suggested and the `SomeClass implements

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Thu, Mar 20, 2025, at 11:09 AM, Gina P. Banyard wrote: > Frankly, the comment from u\phuncky [1] mentioning the possibility of > bad interactions with default interface methods (something I think is > more important than this) is reinforcing my opinion that this RFC solve > the problem in a

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Sat, Mar 15, 2025, 11:25 Juris Evertovskis wrote: > The key point, hoewever, seems to be that the naming of the feature is > excremental and very easy to misunderstand. I suppose the naming issue can > be solved separately (if a better name is found) and the documentation can > use a different

Re: [PHP-DEV] [VOTE] Optional Interfaces

Hi, https://wiki.php.net/rfc/optional-interfaces > I voted yes as we have got a specific use case in core - user stream wrapper. More details can be found in https://github.com/php/php-src/issues/10506 . Regards Jakub

Re: [PHP-DEV] [VOTE] Optional Interfaces

On 2025-03-14 10:09, Juris Evertovskis wrote: Hello, I've opened the vote on the Optional interfaces RFC. https://wiki.php.net/rfc/optional-interfaces Implementation: https://github.com/php/php-src/pull/17288 Discussion: https://externals.io/message/126185 The voting will be closed on 2025-

Re: [PHP-DEV] [VOTE] Optional Interfaces

On Fri, Mar 14, 2025 at 10:52 AM Jakub Zelenka wrote: > Hi, > > https://wiki.php.net/rfc/optional-interfaces >> > > I voted yes as we have got a specific use case in core - user stream > wrapper. More details can be found in > https://github.com/php/php-src/issues/10506 . > > Ah I should have pro

Re: [PHP-DEV] [VOTE] First Class Callables in constant expressions

Hi Am 2025-02-06 16:40, schrieb Volker Dusch: We just started the vote on the "First Class Callables in constant expressions" RFC. References: RFC: https://wiki.php.net/rfc/fcc_in_const_expr Implementation: https://github.com/php/php-src/pull/17213 Discussion: https://externals.io/message/1262

Re: [PHP-DEV] [VOTE] [RFC] Consolidate Coding Standards Policy Document

On Tue, 14 Jan 2025, Derick Rethans wrote: > I have just opened the vote on the "Consolidate Coding Standards > Policy Document". The vote will run until January 28st, 16:00 UTC. > > > https://wiki.php.net/rfc/consolidate-coding-standard-policy-document#proposed_voting_choices I have clo

Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

On 27-11-2024 22:58, Tim Düsterhus wrote: Hi On 11/27/24 22:50, Juliette Reinders Folmer wrote: One thing I'm wondering about - and of which I saw no mention in the RFC nor in the preceding discussion - knowing that function names are case-insensitive, how is ambiguity handled when _calling_ a

Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

Hi On 11/27/24 22:50, Juliette Reinders Folmer wrote: One thing I'm wondering about - and of which I saw no mention in the RFC nor in the preceding discussion - knowing that function names are case-insensitive, how is ambiguity handled when _calling_ a callback stored in a (class) constant ? N

Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

On 27-11-2024 15:03, Tim Düsterhus wrote: Hi Am 2024-11-13 14:40, schrieb Tim Düsterhus: we just started the vote the the "Support Closures in constant expressions" RFC. Please find the following resources for your reference: RFC: https://wiki.php.net/rfc/closures_in_const_expr Implementatio

Re: [PHP-DEV] [VOTE] Support Closures in constant expressions

Hi Am 2024-11-13 14:40, schrieb Tim Düsterhus: we just started the vote the the "Support Closures in constant expressions" RFC. Please find the following resources for your reference: RFC: https://wiki.php.net/rfc/closures_in_const_expr Implementation: https://github.com/php/php-src/pull/1645

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

On Tue, 5 Nov 2024 at 19:35, Eric Norris wrote: > > > That said, as I mentioned above I would be fine with removing cookie > > > jar persistence if that was necessary to secure a passing vote, since > > > it's not our primary focus. > > > > Given the information regarding the TLS re-use, the cook

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

> > That said, as I mentioned above I would be fine with removing cookie > > jar persistence if that was necessary to secure a passing vote, since > > it's not our primary focus. > > Given the information regarding the TLS re-use, the cookie sharing is my > only remaining concern. In fact with cook

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

> > Here's a pull request indicating that the curl team considers TLS > > reuse safe: https://github.com/curl/curl/pull/1917. I believe they > > consider it a vulnerability if you are able to make curl incorrectly > > reuse a TLS session with differing TLS settings. > > Thank you. That would be use

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

Hi Am 2024-10-28 16:31, schrieb Eric Norris: I think it's interesting to note that within a request, users are still vulnerable to accidentally over-sharing cookies. It's unclear to Yes. me why we would draw the line at persistence, considering it would be opt-in. That is, even if you're not

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

> >> Accidentally sharing a cookie jar for unrelated requests due to a > >> badly > >> chosen `$persistent_id` sounds like a vulnerability to is bound to > >> happen to someone. > > > > I'll admit that I don't have a good response to this, since while I > > agree this is possible, I don't think it

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

Hi Am 2024-10-25 16:29, schrieb Eric Norris: I'm especially concerned, because the documentation for `curl_share_init()` uses `CURL_LOCK_DATA_COOKIE` as the example. I would also assume that sharing a cookie jar amongst several requests is the primary use case for leveraging a curl share handl

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

> On Fri, Oct 25, 2024 at 3:34 AM Tim Düsterhus wrote: > Apologies, I wanted to chime in before the vote started, but I was too > busy. I appreciate that you took the time to respond at all, so thank you. > Persistent handles / resources / objects violate PHP’s shared-nothing > request model, wh

Re: [PHP-DEV] [VOTE] Add persistent curl share handles

Hi Am 2024-10-24 20:20, schrieb Eric Norris: I have opened the vote for "Add persistent curl share handles": https://wiki.php.net/rfc/curl_share_persistence Apologies, I wanted to chime in before the vote started, but I was too busy. Nevertheless I want to share my reasons for voting "no" on

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Fri, Jul 26, 2024, at 1:25 PM, Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > The vote will end on 9 February, probably afternoonish in my timezone. I have now closed the vote on this RFC. The final result is 24 Y

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Mon, Aug 5, 2024, at 8:49 AM, Theodore Brown wrote: > On Fri, July 26, 2024 at 12:25 Larry Garfield wrote: > >> Voting for Asymmetric Visibility is now open. >> >> https://wiki.php.net/rfc/asymmetric-visibility-v2 > > Hi Larry and Ilija, > > Thank you for all your work on this RFC! > > One part

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Fri, July 26, 2024 at 12:25 Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 Hi Larry and Ilija, Thank you for all your work on this RFC! One part that doesn't make sense to me is this sentence near the end in the "R

Re: [PHP-DEV] [Vote] Property Hook performance improvements

On Mon, Jul 15, 2024, at 2:05 PM, Larry Garfield wrote: > Hi all. I have just opened the voting on the property hook > (performance) improvement RFC. > > https://wiki.php.net/rfc/hook_improvements > > With the readonly bits pushed out to later, this is probably the > shortest RFC I have ever wri

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On 26/07/2024 19:39, Andreas Heigl wrote: On 26 July 2024 18:25:53 UTC, Larry Garfield wrote: The vote will end on 9 February, probably afternoonish in my timezone. That's a pretty long voting period... It seems he meant the 9th of August.

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Fri, Jul 26, 2024, at 6:54 PM, Bilge wrote: >> Presumably the proposed PHP version is wrong? No, this is still within the window to target 8.4. --Larry Garfield

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On Fri, Jul 26, 2024, at 6:25 PM, Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > The vote will end on 9 February, probably afternoonish in my timezone. > > -- > Larry Garfield > la...@garfieldtech.com Sigh. And

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

> > Presumably the proposed PHP version is wrong?

Re: [PHP-DEV] [Vote] Asymmetric visibility v2

On 26 July 2024 18:25:53 UTC, Larry Garfield wrote: > Voting for Asymmetric Visibility is now open. > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > The vote will end on 9 February, probably afternoonish in my timezone. > That's a pretty long voting period... -- Andreas Heigl

Re: [PHP-DEV] [VOTE] Correctly name the rounding mode and make it an Enum

Hi On 7/3/24 08:32, Tim Düsterhus wrote: RFC Text: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum Discussion Thread: https://externals.io/message/123472 The RFC has been accepted unanimously with 34 (yes) to 0 (no) votes. I'll now make the final adjustments to

Re: [PHP-DEV] [VOTE] Correctly name the rounding mode and make it an Enum

Hi On 7/3/24 08:32, Tim Düsterhus wrote: RFC Text: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum Discussion Thread: https://externals.io/message/123472 I have just added a link to the implementation of the enum and the changes to `round()` to the RFC. Saki will

Re: [PHP-DEV] [VOTE] PDO driver specific parsers

Hi, Il 03/06/2024 09:27, Matteo Beccati ha scritto: Hi internals, I've just opened the vote for the "PDO driver specific parsers" RFC. The RFC contains a single vote which requires a 2/3 majority to pass. Voting runs 2 weeks until 2024-06-17 15:00 UTC. Please find the following resources fo

Re: [PHP-DEV] [VOTE] Casing of acronyms in class and method names

Hi On 4/22/24 15:26, Tim Düsterhus wrote: Please find the following resources for your references: RFC Text: https://wiki.php.net/rfc/class-naming-acronyms Discussion Thread: https://externals.io/message/122975 Pre-RFC Discussion Thread: https://externals.io/message/120959 Related discussion in

Re: [PHP-DEV] [VOTE] PHP 8.4 Release Managers

Il 17/04/2024 15:38, Sergey Panteleev ha scritto: Hi all! Voting ended and Derick's script counted the votes [1]. Our "rookie" PHP 8.4 release managers are: - Calvin Buckley - Saki Takamachi Our "veteran" is the PHP 8.3 release manager Eric Mann. Congrats to the RMs! Cheers -- Matteo Bec

Re: [PHP-DEV] [VOTE] PHP 8.4 Release Managers

Hi all! Voting ended and Derick's script counted the votes [1]. Our "rookie" PHP 8.4 release managers are: - Calvin Buckley - Saki Takamachi Our "veteran" is the PHP 8.3 release manager Eric Mann. Further steps are described in the New release manager checklist [2], I believe you can discuss i

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月21日(水) 9:16 youkidearitai : > > 2024年2月19日(月) 18:55 youkidearitai : > > > > -- Forwarded message - > > From: youkidearitai > > Date: 2024年2月19日(月) 18:46 > > Subject: Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions &g

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月19日(月) 18:55 youkidearitai : > > -- Forwarded message - > From: youkidearitai > Date: 2024年2月19日(月) 18:46 > Subject: Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions > To: > > > 2024年2月7日(水) 5:19 youkidearitai : > > &g

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月7日(水) 12:56 Tim Starling : > > On 7/2/24 13:43, Ayesh Karunaratne wrote: > > > > Hi Tim, > > Now that the RFC is restarted, could you mention some examples in > > Georgian that might be good test cases? > > > > I was thinking there might be some good test cases in Turkish, but > > couldn't f

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

On 7/2/24 13:43, Ayesh Karunaratne wrote: Hi Tim, Now that the RFC is restarted, could you mention some examples in Georgian that might be good test cases? I was thinking there might be some good test cases in Turkish, but couldn't find any. The RFC has examples (https://github.com/php/php-

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

> > I see. I'll change mb_ucfirst using titlecase. > > Per my comments a month ago on the GitHub issue , I think it is much > better to use title case for mb_ucfirst() than to use upper case, > since conversion of the first character to upper case has the effect > of corrupting text in the Georgian

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月7日(水) 4:49 youkidearitai : > > 2024年2月7日(水) 2:56 Juliette Reinders Folmer > : > > > > On 6-2-2024 3:40, youkidearitai wrote: > > > 2024年2月6日(火) 8:33 Tim Starling : > > >> On 2/2/24 20:27, youkidearitai wrote: > > >> > > >> I see. I'll change mb_ucfirst using titlecase. > > >> > > >> Per my

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月7日(水) 2:56 Juliette Reinders Folmer : > > On 6-2-2024 3:40, youkidearitai wrote: > > 2024年2月6日(火) 8:33 Tim Starling : > >> On 2/2/24 20:27, youkidearitai wrote: > >> > >> I see. I'll change mb_ucfirst using titlecase. > >> > >> Per my comments a month ago on the GitHub issue , I think it is

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

On 6-2-2024 3:40, youkidearitai wrote: 2024年2月6日(火) 8:33 Tim Starling : On 2/2/24 20:27, youkidearitai wrote: I see. I'll change mb_ucfirst using titlecase. Per my comments a month ago on the GitHub issue , I think it is much better to use title case for mb_ucfirst() than to use upper case, s

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月6日(火) 8:33 Tim Starling : > > On 2/2/24 20:27, youkidearitai wrote: > > I see. I'll change mb_ucfirst using titlecase. > > Per my comments a month ago on the GitHub issue , I think it is much better > to use title case for mb_ucfirst() than to use upper case, since conversion > of the firs

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

On 2/2/24 20:27, youkidearitai wrote: I see. I'll change mb_ucfirst using titlecase. Per my comments a month ago on the GitHub issue , I think it is much better to use title case for mb_ucfirst() than to use upper case, since conversion of the first character to upper case has the effect of

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

2024年2月2日(金) 18:15 Ayesh Karunaratne : >> >> On Fri, Feb 2, 2024 at 2:00 AM youkidearitai >> wrote: >> >> > Hi, Internals >> > >> > I have just opened the voting "Multibyte ucfirst and lcfirst functions" >> > RFC. >> > https://wiki.php.net/rfc/mb_ucfirst >> > >> > Voting will be open until Februar

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

> > On Fri, Feb 2, 2024 at 2:00 AM youkidearitai > wrote: > > > Hi, Internals > > > > I have just opened the voting "Multibyte ucfirst and lcfirst functions" > > RFC. > > https://wiki.php.net/rfc/mb_ucfirst > > > > Voting will be open until February 26th, 2024 at 01:00 UTC. > > > > Cheers > > Yuya

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

On Fri, Feb 2, 2024 at 2:00 AM youkidearitai wrote: > Hi, Internals > > I have just opened the voting "Multibyte ucfirst and lcfirst functions" > RFC. > https://wiki.php.net/rfc/mb_ucfirst > > Voting will be open until February 26th, 2024 at 01:00 UTC. > > Cheers > Yuya > > -- > -

Re: [PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository

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 a

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

I have voted no. Not because I disagree with the proposal, but because I think the timeline is wrong. First, we should identify a way to deprecate and disable the option of naming anonymous classes. I suggest we deprecate this "feature" in PHP 8.4 and remove it in PHP 9.0, as well as making the ano

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

On Mon, Jan 15, 2024, at 13:54, Nuno Maduro wrote: > On Mon, 15 Jan 2024 at 10:36, Daniil Gentili > wrote: > > > Hi all, > > > > I've opened voting for the final-by-default anonymous classes RFC: > > https://wiki.php.net/rfc/final_by_default_anonymous_classes > > > > Regards, > > > > Daniil Genti

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

Hi Daniil On Mon, Jan 15, 2024 at 11:36 AM Daniil Gentili wrote: > > Hi all, > > I've opened voting for the final-by-default anonymous classes RFC: > https://wiki.php.net/rfc/final_by_default_anonymous_classes It seems you've edited the text of the poll. Doing so disassociates the existing votes

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

On Mon, 15 Jan 2024 at 10:36, Daniil Gentili wrote: > Hi all, > > I've opened voting for the final-by-default anonymous classes RFC: > https://wiki.php.net/rfc/final_by_default_anonymous_classes > > Regards, > > Daniil Gentili. > Hi Daniil, Thank you for your work on this RFC. In my opinion, th

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

Am 15.01.2024 um 11:35 schrieb Daniil Gentili: I've opened voting for the final-by-default anonymous classes RFC: https://wiki.php.net/rfc/final_by_default_anonymous_classes I am confused by the voting option "Make final anonymous classes final by default". You mean "Make anonymous classes f

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

> Am 15.01.2024 um 11:57 schrieb Nicolas Grekas : > > Hi Daniil, > > I've opened voting for the final-by-default anonymous classes RFC: >> https://wiki.php.net/rfc/final_by_default_anonymous_classes >> > > I voted against the proposal because as I mentioned in the previous thread > on the sam

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

Hi Daniil, I've opened voting for the final-by-default anonymous classes RFC: > https://wiki.php.net/rfc/final_by_default_anonymous_classes > I voted against the proposal because as I mentioned in the previous thread on the same topic, this is a backward compatibility break that lacks ground but

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

Am 03.12.23 um 19:34 schrieb Larry Garfield: On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote: On 3 December 2023 14:49:12 GMT, Nikita Popov wrote: On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: Hi all, I've just opened voting for the final anonymous classes RFC @ https://wiki.ph

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote: > On 3 December 2023 14:49:12 GMT, Nikita Popov wrote: >>On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: >>> Hi all, >>> >>> I've just opened voting for the final anonymous classes RFC @ >>> https://wiki.php.net/rfc/final_anonymous_cla

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

Am 03.12.2023 um 15:49 schrieb Nikita Popov: For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. I voted "no" for exactly the same reason. -- PHP Internals - PHP Runtime Development Mailing Lis

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

On 3 December 2023 14:49:12 GMT, Nikita Popov wrote: >On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: >> Hi all, >> >> I've just opened voting for the final anonymous classes RFC @ >> https://wiki.php.net/rfc/final_anonymous_classes. >> >> Voting started now, and will run until December 18

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

On Sun, Dec 3, 2023, at 16:05, Nicolas Grekas wrote: > Hello Nikita, > >> > I've just opened voting for the final anonymous classes RFC @ >> > https://wiki.php.net/rfc/final_anonymous_classes. >> > >> > Voting started now, and will run until December 18th 2023, 00:00 GMT. >> >> For the record,

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

Hello Nikita, > > I've just opened voting for the final anonymous classes RFC @ > > https://wiki.php.net/rfc/final_anonymous_classes. > > > > Voting started now, and will run until December 18th 2023, 00:00 GMT. > > For the record, I've voted against this proposal because I believe it > should ha

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

Hi Nikita, For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a

Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes

On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: > Hi all, > > I've just opened voting for the final anonymous classes RFC @ > https://wiki.php.net/rfc/final_anonymous_classes. > > Voting started now, and will run until December 18th 2023, 00:00 GMT. For the record, I've voted against this

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

Thank you for catching this. This is a mistake that I have just fixed. This part states now: > ROUND_TOWARD_ZERO (equivalent of PHP_ROUND_TOWARD_ZERO) alias of ROUND_DOWN > ROUND_AWAY_FROM_ZERO (equivalen

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

> On Nov 15, 2023, at 11:25, Jorg Sowa wrote: > > Hello internals! > I have just opened voting on the RFC to add 4 new rounding modes to round() > function. > > Voting will end November 30th, 00:00 GMT. > > Link: > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > > Kind regards,

Re: [PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim

2023年11月19日(日) 5:11 mickmackusa : > Can you please clear up some ambiguity for me regarding mb_trim()? > > Is it true that the .. character range syntax will not be supported at all or > is it merely that that syntax will not be allowed when one of the range > limits includes a multibyte charact

Re: [PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim

> > Voting is now closed. mb_trim, mb_ltrim and mb_rtrim of result is yes:15, > no:0. > I will soon change from draft pull request > (https://github.com/php/php-src/pull/12459) to normal pull request. > > Regards > Yuya. > > Hi Yuya, Can you please clear up some ambiguity for me regarding mb_trim(

Re: [PHP-DEV][VOTE][RFC] Add multibyte trim function mb_trim, mb_ltrim and mb_rtrim

2023年11月3日(金) 0:10 youkidearitai : > > Hi, Internals > > I have just opened voting on the RFC to mb_trim. > Voting started now, and will run until November 17th, 24:00 GMT > > Link: > https://wiki.php.net/rfc/mb_trim#voting > > (It's my first time so please tell me if I'm any wrong) Hi, Internals

Re: [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

On Wed, 1 Nov 2023, Derick Rethans wrote: > I have just opened voting on the RFC to unbundle imap, pspell, and > oracle integrations. > > Each extension can be voted on separately. Voting started now, and > will run until November 15th, 24:00 GMT. > > Link: https://wiki.php.net/rfc/unbundle_im

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 12 Oct 2023, at 19:50, Jordan LeDoux wrote: > That's not how voting works in the PHP project. The 2/3 is for whether or not > the feature change should be made at all. In the case that there are multiple > implementations or variations, the choice between those is usually simple > majority.

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On Wed, Oct 4, 2023 at 5:08 PM wrote: > Also the poll for increasing from cost 11 to cost 12 should be a 2/3 > majority to get cost 12. Since the poll for increasing from cost 10 to cost > 11 is a 2/3 majority. You can think of this as a 2/3 majority poll to > increase to cost 11 followed by a 2/

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi Let me link your Fediverse reply for reference as well: https://infosec.exchange/@sc00bz/78818937154254 On 10/5/23 02:07, st...@tobtu.com wrote: I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12 is ~1 kH/s/GPU and the accepted limit for good settings is

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/21/23 19:26, Tim Düsterhus wrote: I just opened the vote for the "Increasing the default BCrypt cost" RFC. The RFC contains a two votes, one primary vote that requires a 2/3 majority to pass and a secondary vote deciding on the new costs with a simple majority. Voting runs 2 weeks until

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

> On 09/22/2023 2:04 AM CDT Nicolas Grekas wrote: > > > I was wondering if you considered also raising the Argon2 default cost? Has > this been discussed? > Argon2 defaults are actually quite high at a theoretical speed of ~1.3 kH/s/GPU (960,000,000,000/(64*1024^2)/(3*4-1) or in general band

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12 is ~1 kH/s/GPU and the accepted limit for good settings is <10 kH/s/GPU. Cost 12 is 10x stronger than it needs to be as a *minimum*. I believe cost 10 is a good *default* for the next 1-3 years and cost 11 should b

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 25 Sep 2023, at 18:07, Tim Düsterhus wrote: > I've now did the maths and you really need rate limiting no matter if you use > costs 10, 11 or 12, so I believe the DoS argument is a little moot. Yes, someone being malicious could easily generate enough requests to create an Denial of Service

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/25/23 21:43, Levi Morrison via internals wrote: I did a tiny bit of my own research, and could not find any recommendations more specific than "10 or more" as the cost factor. Typically, the advice is "use a more modern system like argon2id". Please see this email of mine regarding Arg

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Yes, BCrypt uses only the first 72 bytes for hash generation. You can test it with: var_dump(password_verify(str_repeat('a', 72).'sdfsdf', password_hash(str_repeat('a', 80), PASSWORD_BCRYPT))); But I would not consider this an issue. Users rarely create passwords longer than 72 bytes. 72 bytes is

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

> Please find the following resources for your references: > > RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023 > Discussion Thread: https://externals.io/message/121004 > Feedback by a Hashcat team member on Fediverse: > https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075 I d

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/22/23 10:46, Craig Francis wrote: On 22 Sep 2023, at 08:04, Nicolas Grekas wrote: For the record, I voted for 11 because I think it's nicer to end users (I guess many don't know they could have a potential DoS vector via password submissions), and also because it's going to be easy t

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/25/23 06:20, Theodore Brown wrote: Thanks for your work on this. I think bumping the default BCrypt cost from 10 to 11 is reasonable, as this typically adds less than 100 milliseconds additional latency, which shouldn't be too noticeable for users logging in. However, I am concerned a

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On Thu, Sep. 21, 2023 at 12:26 PM Tim Düsterhus wrote: > I just opened the vote for the "Increasing the default BCrypt cost" RFC. > The RFC contains a two votes, one primary vote that requires a 2/3 > majority to pass and a secondary vote deciding on the new costs with a > simple majority. Voting

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

more results on ARM: RK3399 - Cortex-A7x Cost 10: 10.694221 total (0.106942 per hash) Cost 11: 21.360409 total (0.213604 per hash) Cost 12: 42.692786 total (0.426928 per hash) RK3399 - Cortex-A5x Cost 10: 15.146773 total (0.151468 per hash) Cost 11: 30.272059 total (0.302721 per hash) Cost 12:

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

On 22 Sep 2023, at 08:04, Nicolas Grekas wrote: > For the record, I voted for 11 because I think it's nicer to end users (I > guess many don't know they could have a potential DoS vector via password > submissions), and also because it's going to be easy to raise again in > 8.5/9.0. +1 I can

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/22/23 09:04, Nicolas Grekas wrote: For the record, I voted for 11 because I think it's nicer to end users (I guess many don't know they could have a potential DoS vector via password submissions), and also because it's going to be easy to raise again in 8.5/9.0. I was wondering if you c

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

I just opened the vote for the "Increasing the default BCrypt cost" RFC. > The RFC contains a two votes, one primary vote that requires a 2/3 > majority to pass and a secondary vote deciding on the new costs with a > simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC. > > Please find t

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Le 21/09/2023 à 19:26, Tim Düsterhus a écrit : Hi I just opened the vote for the "Increasing the default BCrypt cost" RFC. The RFC contains a two votes, one primary vote that requires a 2/3 majority to pass and a secondary vote deciding on the new costs with a simple majority. Voting runs 2 we

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

Hi On 9/21/23 19:26, Tim Düsterhus wrote: I just opened the vote for the "Increasing the default BCrypt cost" RFC. The RFC contains a two votes, one primary vote that requires a 2/3 majority to pass and a secondary vote deciding on the new costs with a simple majority. Voting runs 2 weeks until

Re: [PHP-DEV] [VOTE] Support optional suffix parameter in tempnam

On Tue, Aug 29, 2023, at 1:57 AM, Levi Morrison via internals wrote: > On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus wrote: >> >> Hi Athos >> >> On 8/27/23 04:02, Athos Ribeiro wrote: >> > I am moving this RFC [1] to the voting phase. Voting will be open for the >> > next 2 weeks, until September

  1   2   3   4   5   6   7   8   9   10   >