Re: [PHP-DEV] [RFC][Discussion] Policy release process update

Thank you Jakub for tackling the problem of inconsistency between policy and practice. Taking my PR as case study, under this policy I am allowed to choose whatever approach I want? Either deprecation or validation error. https://github.com/php/php-src/pull/15647 > - Behavior changes in undefine

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Thank you all for the feedback. > I don't fundamentally disagree with the attempt to codify something > here, but ultimately the PHP language does and will continue to profit > from some flexibility in these regards. @Bob, I agree that flexibility is desired. That's why I would like to have rathe

Re: [PHP-DEV] Closure::getCurrent() for recursion

I gave this example only to point out that this case should be mentioned in the RFC to dispel doubts what's intended and eventually put such test case into the PR. Kind regards, Jorg

[PHP-DEV] [RFC] [Discussion] Minor version compatibility

Thank you all for the feedback on the topic of BC breaks in argument validation https://news-web.php.net/php.internals/126706 I have collected all concerns, prepared an RFC for this change, and I'm opening discussion on its content: https://wiki.php.net/rfc/minor-version-compatibility Since this

Re: [PHP-DEV] Consensus on argument validation for built-in functions

Thank you all for inputs. There is no consensus at all, so we must go through RFC process. I will sum up feedback and I will create the RFC this weekend. Kind regards, Jorg

Re: [PHP-DEV] Closure::getCurrent() for recursion

Hello Ilija, Nice addition! I thought about edge cases and what the desired output is with nested closures? Example:

Re: [PHP-DEV] [RFC] [Discussion] Optional interfaces

Hello Juris, There is some uncertainty for me on how this approach would work with namespaces. Let's get this example: https://3v4l.org/bI1Rj I would expect to get the error message that I forgot to insert `use Stringable;`. But with your idea everything is fine. I don't like such ambiguity and I

[PHP-DEV] Consensus on argument validation for built-in functions

RFC, but as described by a few people in the discussions, we can avoid it having the consensus. What do you think? Kind regards, Jorg Sowa

Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])

ty to beginners' understanding of the typing system. The second option with $_ is BC on the other hand, so both options are unsatisfying. And honestly, I don't have good ideas for it. Kind regards, Jorg Sowa

Re: [PHP-DEV] Return When

Hey Volodymyr, You can already write: $success or throw new Exception('I am here'); Honestly, I don't see a good reason to introduce another syntax to do the same thing. Kind regards, Jorg Sowa

Re: [PHP-DEV] Updates needed to various RFCs

Thank you, Juliette. I added missing information to my RFC: Raising zero to the power of negative number. Kind regards, Jorg

Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function

> You don’t make any effort to help or provide constructive criticism; you just love to (incorrectly) tell everyone what they're doing wrong and how they should be doing it, without adding anything constructive to the conversation. Please limit to the arguments on the topic, not a person. The arg

Re: [PHP-DEV] [RFC] Static Constructor

Hi Erick, It would be useful to include the example of Singleton implementation with a static constructor. Kind regards, Jorg

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

> It should also be noted that ceil/floor is very English specific terminology that may not be immediately obvious to non-English speakers, thus my preference for using some variation of towards positive/negative infinity. This statement is subjective in my opinion. For me, it's the contrary, that

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

Hey Saki, I like this change. When I was implementing additional rounding modes for the next PHP version I was initially struggling with the naming and this change will be helpful. I have only one concern about the names `NegativeInfinity` and `PositiveInfinity`. They may be too formal from the us

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

> I don't think there are any other "functions" like this. What about list(), isset(), print(), echo(), require(), include(), unset(), empty()? We use them the same way as functions, but those are not real functions. Kind regards, Jorg

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

I like the proposition and I like the idea of $since parameter, however, this option is too ambiguous about what should store. Should it store the PHP version, package version, or the date? What about setting this parameter vaguely as the boolean we can pass? #[Attribute(Attribute::TARGET_METHOD

[PHP-DEV] Re: [RFC][Vote] Raising zero to the power of negative number

Hi everyone, The vote has been closed and accepted with 27 votes for yes, and 0 for no. Thanks to everyone who participated in the vote and discussion. Kind regards, Jorg

Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

Hello Yuya, I don't think modifying voted RFCs is allowed despite the size of the change. Moreover, there are no dates of the voting included in the description of the RFC so it's not clear for visitors when exactly the RFC has been approved. Kind regards, Jorg

[PHP-DEV] [RFC][Vote] Raising zero to the power of negative number

Hello everyone I've just opened voting for the RFC Raising zero to the power of the negative number Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number Voting started now, and will end on April 20 2024, 00:00 UTC. Kind regards, Jorg

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

Thank you Marc for your opinion. It makes sense to me that we should have the possibility to mimic the IEEE-754 standard, thus we should have `fpow` function as well. I have updated the RFC and would like to start the voting if there are no new comments. Kind regards, Jorg Sowa

Re: [PHP-DEV] RFC Proposal : Allows calling non-static public methods through the __callStatic magic method instead of throwing an error.

For the reference to the others: https://3v4l.org/UmPVo Kind regards, Jorg

Re: [PHP-DEV] RE: Testing new list server

Hello Derick, there is something wrong. I don't get all of the emails from the new setup, only part. Examples of emails I didn't receive: - https://externals.io/message/122391 - https://externals.io/message/122390 - https://externals.io/message/122388 I'm using Gmail and Spam doesn't contain any o

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

Hello everyone, If there is no other feedback I would like to start voting in the next few days. Kind regards, Jorg

Re: [PHP-DEV] [RFC][Vote] Promote the PHP Foundation

Hello Jim, shoudl this RFC be placed into the Policies repository as it was accepted? https://github.com/php/policies Kind regards, Jorg

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

t much of the deprecated code will be removed in PHP 9.0, maybe it's worth discussing how long should be period between 9 and 10? Kind regards, Jorg Sowa

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

Thank you for the suggestions. I agree that error message should be more meaningful. I changed it. The main driver of this change is to match the division by zero behavior for both operators which can operate on both integers and floats. Would it make sense to create a function `fpow` similarly to

[PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

Hello everyone! I want to start the discussion on the RFC: Raising zero to the power of negative number Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number Kind regards, Jorg

[PHP-DEV] Google Summer of Code 2024

even if no idea is taken, we would have a collection of ideas that could be an inspiration for non-students. Kind regards, Jorg Sowa

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

> It should contain the consolidated unified policy documentation that is > "currently" active. > The other option is what we currently have, and I am proposing to go > away from. So the idea is that this repository is not a > collection of the accepted policy *amendments* (or *replacements*), > a

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

Hey Derick, Thank you for proposing this change. As a author of comment you mentioned I believe this will help new maintainers to get all the information about the RFC process from one place. I have one question regarding the future changes. Do you see it would be possible to make amendment to the

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

I'm sorry for the confusion. I followed the guide for the voting stating that the first voting is primary, and rest are secondary, which don't require 2/3 votes on yes. https://wiki.php.net/RFC/voting#voting As this was my first RFC I was struggling a little bit, because the whole description abo

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

Hello everyone, The poll has been closed. The RFC has been accepted with 19 votes yes and 0 votes no. Creating aliases for Intl extension constants has been accepted with 10 votes yes and 6 votes no. Thank you all for participating. Kind regards, Jorg

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] RFC Proposal - static modifier for classes

Hi Lanre, I like your idea and I was even thinking about proposing the same addition. The thing that is missing in the description is how the static class should handle magic methods. Should they be disabled for them? One plus of static classes which exist in other languages are that we wouldn't

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

Thank you for your input Levi, this perspective wasn't mention before. I agree with deprecation, that's why I removed this part from the RFC. I left separate vote on creating aliases for the extension though, as from the discussion this was not so certain and clear to everyone. Kind regards, Adam

[PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

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 I'm sorry for previous message, but completely missed the title of the message. Ki

[PHP-DEV] [VOTE] [RFC]

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, Jorg

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

Thank you for your comments. Listening to the opinions I will not include deprecation of the constants and introducing the RoundingMode enum in this RFC. Sorry for the delay. I will start eventually voting on the RFC tomorrow. Kind regards, Jorg

Re: [PHP-DEV] Basic Type Alias

I really like the idea and I would love to see it in PHP. I'm wondering however, what would be the scope of the feature and how complex would be designed type system. Examples I saw in this thread could be easily replaced with union and intersection types (i.e. numeric as int|float). In my opinion,

Re: [PHP-DEV] Two new functions array_first() and array_last()

> Sure in many use cases undefined and null can be equivalent, but there > are other use cases and considering the fact that php does not have a > user level "undefined" value. It should at least attempt to not be > ambiguous when possible. Instead of being ambiguous by default, > requiring the use

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

Hello Daniil, I like this proposition. I never understood why the JIT is disabled by the ini setting `buffer_size` rather than other simple 'switch' like setting. Kind regards, Jorg

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

> I don't think deprecating the constants in the version where the aliases are introduced is a good idea. I removed the deprecation. You are right. > I will also echo Tim's idea of using an enum instead and a union type. > For the namespace, I think it would make sense to use Maths\RoundingMode

[PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

Thank you all for the discussion. I modified description of the RFC and added deprecation of constants ROUND_UP and ROUND_DOWN from Intl extension as an additional voting. Thanks also for input about possible mode ROUND_STOCHASTIC, however I think it's the idea for the extension and not the additi

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hello, Recently I was trying to fix and clean some of the stuff within the BCmath extension along with Girgias who helped me. I wanted to enrich this extension with similar functions that GMP contains and improve the performance, however, I went to some conclusions and stopped it. 1. BCMath exten

Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function

Thank you all for the comments. The naming brought some constructive discussion. My preferred solution would be inconsistent PHP_ROUND_AWAY_FROM_ZERO and PHP_ROUND_TOWARD_ZERO as those are friendlier to the most of developers and are not possible to mistake with other modes. I would go even one st

[PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function

Hello everyone, I would like to start the RFC process about adding 4 new rounding modes to the round() function. As the topic was previously discussed and the change is quite small, I would like to start the voting on the beginning of next week. RFC: https://wiki.php.net/rfc/new_rounding_modes_t

[PHP-DEV] Re: Introducing 2 new modes to round function

Hello everyone, As I am not sure what I should next I decided to follow the formal way and I created the RFC for the change. I will start voting soon. Please let me know if you have any suggestions. RFC under discussion: https://wiki.php.net/rfc/new_rounding_modes_to_round_function

Re: [PHP-DEV] Introducing 2 new modes to round function

I had no idea about your PR Mark. It's pity to see that many improvements (even simple) like this eventually was not implemented, despite the effort authors put into. I have created PR with the change. https://github.com/php/php-src/pull/12056 If you think I should proceed with RFC please let me

Re: [PHP-DEV] Introducing 2 new modes to round function

Thank you for your suggestions. I added two remaining modes and I think it's complete now. I changed the names to `PHP_ROUND_CEILING` and `PHP_ROUND_FLOOR` to be consisted with rounding modes in number_format() function. I'm not sure about `PHP_TOWARD_ZERO` and 'PHP_AWAY_FROM_ZERO` as in there it'

[PHP-DEV] Introducing 2 new modes to round function

Hello internals! I would like to propose introducing two new modes to the function `round()`: PHP_ROUND_DOWN and PHP_ROUND_UP. Those modes are highly requested as you can see by the comments on round documentation page. First comment mentioning about those modes has 309 votes as of today. Introdu

Re: [PHP-DEV] [VOTE] Interface Default Methods

> So, here's a crazy thought: why do inheritance, interfaces, and traits > need to be separate at all? > > At some level, they're all ways of composing a class with different > restrictions, e.g. inheritance requires a single parent, interfaces must be > abstract, traits don't interact with typing,

[PHP-DEV] Re: RFC Karma Request: deprecation of ISO_8601 constants

Hello again! I didn't get any response and I'm not sure then whether I followed everything correctly. I want to write an RFC about deprecating the constants ISO_8601 and RFC7231 which I sent to the mailing list while ago for discussion. If I miss anything I would be glad for assistance. Kind reg

[PHP-DEV] RFC Karma Request: deprecation of ISO_8601 constants

Hello, I would like to request for RFC Karma. I want to create RFC for deprecation of constants ISO_8601. My wiki account is jorg_sowa. Kind regards, Jorg

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

> In my opinion, since it isn't, and likely never was, a legal ISO8601 > string, it's a no-brainer that it should be deprecated. (it's at least > been illegal since iso8601:2004 released in 2004) I thought the same when I started the discussion. It's not good promotion for PHP, when every mention

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

Hey, Native implementation of the function array_find would decrease number of lines needed to perform basic loops over the arrays from 4-6 lines to just 1. And I recollect a few times when the argument of reducing lines of code needed to type was a valid reason of implementing the change. Moreove

Re: [PHP-DEV] RFC [Concept] - Interface Properties

Hello, I agree with David's statement: > So yes anyay, my view is that between interfaces as we have them today, > traits and abstract classes, there isn't a problem which needs to be solved > by now allowing properties on interfaces, but it would open up a likelihood > of encouraging things which

Re: [PHP-DEV] RFC [Discussion]: mb_str_pad

It's a reasonable approach. Thanks for clearing it up. Kind regards, Jorg

Re: [PHP-DEV] RFC [Discussion]: mb_str_pad

Hello, As this is a new function do you consider any namespace for it? Based on passed RFC[1] allowing for namespaces in bundled extensions it would be nice to introduce new functions with namespace. Maybe the namespace could be voted in the RFC separately? Kind regards, Jorg [1] https://wiki.php

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

> What do you mean? Do you mean that the constant was legal at some point? Sorry, but I don't have this knowledge. It's invalid since 2004, but I suppose this format was implemented before then. Undoubtedly the format is invalid now. The usage in 1000 most popular libraries: DATE_ISO8601 (4 packa

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

> How common is it in the wild? I am pretty sure I've used it myself without really thinking many times, which I suspect is common. Knowing how much code would be impacted would determine how we'd go about deprecating it and on what timeline. I'm not sure how would be possible to find out. I sup

[PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

Hello everyone, I would like to propose the deprecation of the constants DATE_ISO8601, DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. Arguments for deprecating DATE_ISO8601: - outdated format, standard has been changed while ago - incompatible with format ISO8601_EXPANDE

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

t 2:29 PM G. P. B. wrote: > On Mon, 15 May 2023 at 23:53, Jorg Sowa wrote: > >> Hello! >> >> I have one concern about the part: >> >> > Emit an E_WARNING when $start or $end is cast to an integer because >> the other boundary input is a number or numeric

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

Hello! I have one concern about the part: > Emit an E_WARNING when $start or $end is cast to an integer because the other boundary input is a number or numeric string. (e.g. range ('5', 'z'); or range (5, 'z');) Doesn't it limit the functionali