Re: [PHP-DEV] [RFC] [VOTE] Disjunctive Normal Form Types

On Fri, 17 Jun 2022 at 16:19, G. P. B. wrote: > Hello internals, > > I've started the vote for the Disjunctive Normal Form Types RFC: > https://wiki.php.net/rfc/dnf_types > > The vote will last for 2 weeks and end on the 1st of July > I'm glad to announce that the RFC has

Re: [PHP-DEV] Make iterator_to_array() accept all iterables

On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus wrote: > Hi Internals > > I've come across a case where it would've been useful if > `iterator_to_array()` would accept iterable instead of Traversable to > avoid checking whether the input variable already is an array. > > To not repeat what I've

[PHP-DEV] [RFC] [VOTE] Disjunctive Normal Form Types

Hello internals, I've started the vote for the Disjunctive Normal Form Types RFC: https://wiki.php.net/rfc/dnf_types The vote will last for 2 weeks and end on the 1st of July Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Disjunctive Normal Form Types

On Sat, 19 Mar 2022 at 16:38, G. P. B. wrote: > Hello internals, > > I would like to open the discussion on the Disjunctive Normal Form (DNF) > types RFC: > https://wiki.php.net/rfc/dnf_types > > The implementation for it is available on my fork, [1] but currently > r

Re: [PHP-DEV] [RFC] [VOTE] Add true as type

On Sun, 29 May 2022 at 15:39, G. P. B. wrote: > Hello internals, > > I've opened the vote for the Add true as type RFC. > https://wiki.php.net/rfc/true-type > > It will run for two weeks and will close on the 12th of June 2022. > The vote is now closed. The RFC has been

[PHP-DEV] [RFC] [VOTE] Add true as type

Hello internals, I've opened the vote for the Add true as type RFC. https://wiki.php.net/rfc/true-type It will run for two weeks and will close on the 12th of June 2022. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Add true as type

Hello internals, I will open voting on this tomorrow unless further comments. https://wiki.php.net/rfc/true-type Best regards, George P. Banyard

Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote: > Hello Internals, > > After the first discussion about this topic > (https://externals.io/message/117608) I have created a preliminary > implementation and an RFC for making implicit boolean type coercions > more strict: > >

Re: [PHP-DEV] Canonicalize "iterable" into "array|Traversable" and Reflection

On Sat, 23 Apr 2022 at 19:19, Marco Pivetta wrote: > Hey George, > > How would the engine behave (with this RFC included) with an inheritance > check? > > Specifically: > > interface A { > function foo(interable $param): iterable; > } > interface B { > function foo(array|\Trabersable

Re: [PHP-DEV] Canonicalize "iterable" into "array|Traversable" and Reflection

On Sat, 23 Apr 2022 at 19:06, Larry Garfield wrote: > On Sat, Apr 23, 2022, at 7:27 AM, G. P. B. wrote: > > Hello internals, > > > > One area the engine currently needs to take special care is dealing with > > the typing relation between iterable, Traversable

[PHP-DEV] Canonicalize "iterable" into "array|Traversable" and Reflection

Hello internals, One area the engine currently needs to take special care is dealing with the typing relation between iterable, Traversable, and array. The change is to canonicalize "iterable" into "array|Traversable" as this then removes this special case. However, doing so breaks Reflection

Re: [PHP-DEV] [RFC] Add true as type

Hello internals, I've expanded on the RFC: https://wiki.php.net/rfc/true-type Please let me know if there are still aspects which need clarification. I will also say that I think enums are far superior to literal types, but only having false and not true is extremely weird to me (and in a pure

Re: [PHP-DEV] NULL Coercion Consistency

On Mon, 11 Apr 2022 at 19:22, Craig Francis wrote: > On Mon, 11 Apr 2022 at 16:14, G. P. B. wrote: > >> But the implementation caused a Type Error when coercing NULL for >>> everyone (even when not using *strict_types=1*), this seems more of an >>> over

Re: [PHP-DEV] NULL Coercion Consistency

On Fri, 8 Apr 2022 at 18:35, Craig Francis wrote: > Hi, > > I've written a new draft RFC to address the NULL coercion problems: > > https://wiki.php.net/rfc/null_coercion_consistency The statement that: > But the implementation caused a Type Error when coercing NULL for everyone > (even when

Re: [PHP-DEV] [RFC] Add true as type

On Sat, 9 Apr 2022 at 12:05, Tim Düsterhus wrote: > Hi > > On 4/8/22 18:47, G. P. B. wrote: > > Now that null and false can be used as standalone types, I think it > makes a > > lot of sense to add true as a value type for the sake of completeness > with > > fals

[PHP-DEV] [RFC] Add true as type

Hello internals, I would like to open the discussion on the RFC to add true as a type. https://wiki.php.net/rfc/true-type Now that null and false can be used as standalone types, I think it makes a lot of sense to add true as a value type for the sake of completeness with false. It also has

Re: [PHP-DEV] Reflection changes due to allow null + false as standalone types RFC

I have just merged the PR with the amended Reflection changes: https://github.com/php/php-src/commit/6039c07a3afd64a42c9b9f1ed994ca971db67a1e Best regards, George P. Banyard

[PHP-DEV] Reflection changes due to allow null + false as standalone types RFC

Hello internals, During the review of the implementation of the RFC which introduces null and false as standalone types there has been a point raised about the changes made to reflection. [1] The current implementation is what follows the RFC, namely to make false|null return a

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

Hello internals, The RFC has been accepted unanimously in favour with 38 votes. Best regards, George P. Banyard

[PHP-DEV] [RFC] Disjunctive Normal Form Types

Hello internals, I would like to open the discussion on the Disjunctive Normal Form (DNF) types RFC: https://wiki.php.net/rfc/dnf_types The implementation for it is available on my fork, [1] but currently relies on a pending PR [2] to make the implementation simpler. DNF types are a way to mix

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

On Thu, 17 Mar 2022 at 15:54, Levi Morrison wrote: > On Sat, Mar 12, 2022 at 10:32 AM G. P. B. > wrote: > > > > I've started voting for the Allow null and false as stand-alone types > RFC: > > https://wiki.php.net/rfc/null-false-standalone-types > > > >

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

On Sat, 12 Mar 2022 at 18:18, David Rodrigues wrote: > Maybe I'm a little late to this discussion, but is there any reason why > *false|null* is allowed but *true|null* is not? > > I can think of few cases where *true|null* could be interesting, but I've > been through situations like this. >

[PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

I've started voting for the Allow null and false as stand-alone types RFC: https://wiki.php.net/rfc/null-false-standalone-types Voting will last for 2 weeks until 26th of March. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] Allow null and false as stand-alone types

Hello internals, I'd like to open voting for this tomorrow. I've expanded a bit the caveat about the specific Reflection change this RFC introduces with handling of null|false compared to other T|null types. https://wiki.php.net/rfc/null-false-standalone-types If there are some final comments

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Wed, 2 Mar 2022 at 09:31, Victor Bolshov wrote: > Hello internals. > > In these dark days for humanity, we as people of civilization, people > of sanity, kind and caring people with children and families - we have > to speak up, loud and clear, in support for Ukraine. To stop Russian >

[PHP-DEV] [RFC] Allow null and false as stand-alone types

Hello internals, As a follow up from the "Allow null as a stand-alone type" where the main talking point was to also allow false to be used as a stand-alone type, a new slightly modified RFC is now proposed: https://wiki.php.net/rfc/null-false-standalone-types The implementation has been updated

Re: [PHP-DEV] Allowing NULL for some internal functions

On Mon, 7 Feb 2022 at 09:34, Christian Schneider wrote: > > If a parameter expects a string, that is what it should be given, and > its the callers' responsibility to ensure that is the case. If they fail to > do so then it's an error just like any other. > > The decision to define e.g. strlen()

Re: [PHP-DEV] Array comparison works completely different than documented?

On Wed, 1 Dec 2021 at 13:56, André Hänsel wrote: > The official documentation contains a conceptual description of array > comparison in > https://www.php.net/manual/en/language.operators.comparison.php#example-113 > . > > Curiously the people who wrote the inofficial spec (I think the HHVM team

Re: [PHP-DEV] Order of properties in (array) cast on PHP 8.1

On Wed, 13 Oct 2021 at 22:45, Benjamin Morel wrote: > Hi internals, > > While running the test suite of one of my libs against PHP 8.1, I noticed > that the order in which properties are returned in an (array) cast has > changed. > > For example when casting an instance of this class to array: >

Re: [PHP-DEV] [RFC] Allow null as standalone type

On Mon, 4 Oct 2021 at 04:33, Levi Morrison wrote: > I don't see the word `void` in the RFC. I think there ought to be > something said about how naked `null` is different or not different > than `void`. Added a section which attempts to explain the difference between both. On Mon, 4 Oct 2021

Re: [PHP-DEV] Unified ReflectionType methods

On Sat, 2 Oct 2021 at 00:54, Andreas Hennings wrote: > Hello list, > I would like to propose new methods for ReflectionType, that would > allow treating ReflectionNamedType and ReflectionUnionType in a > unified way. > This would eliminate the need for if (.. instanceof) in many use cases. > >

[PHP-DEV] [RFC] Allow null as standalone type

Hello internals, I'm proposing a new RFC to make 'null' usable as a standalone type. RFC: https://wiki.php.net/rfc/null-standalone-type GitHub PR: https://github.com/php/php-src/pull/7546 Best regards, George P. Banyard

Re: [PHP-DEV] BC breaking changes in PHP 8.1

On Wed, 22 Sept 2021 at 15:24, Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote: > On Wed, Sep 22, 2021 at 9:01 AM G. P. B. wrote: > >> On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney < >> mweierophin...@gmail.com> wrote: >> >>> Ye

Re: [PHP-DEV] BC breaking changes in PHP 8.1

On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote: > Yesterday, I opened an issue regarding a change in the pgsql extension ( > https://bugs.php.net/bug.php?id=81464). > > PHP 8.0 introduced the concept of "resource objects". Where previously we > would have

Re: [PHP-DEV] [RFC] Never For Argument Types

On Sat, 14 Aug 2021 at 16:01, AllenJB wrote: > This RFC only considers this feature for arguments. Why is it also not a > valid feature for return types? I think it might be useful for abstract > classes and interfaces (for example, the Iterator interface) to force > implementers to specify a

Re: [PHP-DEV] [RFC] Never For Argument Types

On Sat, 14 Aug 2021 at 10:55, Deleu wrote: > Hi Jordan, > > Does it make sense to explain in the RFC the difference between never and > mixed in this context? The RFC vaguely mentions that never can never be > used directly, but if it's limited to abstract class and interfaces, isn't > that

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

ensus before RC stage. > > Cheers > Joe > > On Tue, 20 Jul 2021 at 13:07, Nikita Popov wrote: > >> On Mon, Jul 19, 2021 at 8:16 PM G. P. B. >> wrote: >> >> > On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier < >> guilliam.xav...@gmail.com> >>

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier wrote: > On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas > wrote: > > > > > https://github.com/php/php-src/pull/7259 > > > > Great! Thanks! Interesting how it works out-of-the-box with just this > addition in Zend/zend_language_parser.y: > > ```diff

Re: [PHP-DEV] FFI Type Reflection API

On Wed, 7 Jul 2021 at 10:31, Dmitry Stogov wrote: > Hi, > > Last week, at a PHP conference, we discussed some missing parts of ext/ffi > with one of the most extrimal FFI user - Alexandr Lisachenko. One of the > things he is missing is a FFI Type Reflection API. Actually, this is a > simple and

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

On Mon, 5 Jul 2021 at 20:15, Craig Francis wrote: > Hi Internals, > > I have opened voting on https://wiki.php.net/rfc/is_literal for the > is-literal function. > > The vote closes 2021-07-19 > > The proposal is to add the function is_literal(), a simple way to identify > if a string was written

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

On Mon, 5 Jul 2021 at 13:39, Mike Schinkel wrote: > > On Jul 5, 2021, at 7:14 AM, Rowan Tommins > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It

Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.

On Tue, 29 Jun 2021 at 18:15, Manuel Canga wrote: > Hi, folks, here again with a new purpose: ``` as alternative to Nowdoc > syntax. > > Currently, Nowdoc syntax is very "verbose": > > $string =<<<'CODE' > > Link: '%s' > > CODE; > > Why doesn't something like this?: > > $string =``` > >

Re: [PHP-DEV] [RFC] Deprecate boolean to string coercion

On Tue, 22 Jun 2021 at 23:52, tyson andre wrote: > Hi George P. Banyard, > > > With Ilija we are proposing a short RFC to deprecate coercion from bool > to > > string: > > https://wiki.php.net/rfc/deprecate-boolean-string-coercion > > > > As this is the final day for any RFC to be even able to

Re: [PHP-DEV] Introduce str_left/right In 8.1

On Fri, 25 Jun 2021 at 08:26, Hamza Ahmad wrote: > To George > > > substring of the original string. And by that logic left and right are > > actually linguistically incorrect due to languages being read Right to > Left > > or Top to Bottom. > > Thanks George for pointing out an important aspect

Re: [PHP-DEV] Introduce str_left/right In 8.1

On Thu, 24 Jun 2021 at 07:20, Hamza Ahmad wrote: > HI George, > > > I really don't see the point of these functions. > > These functions provide a clearer semantics for their usage. Are they though? The naming doesn't convey anything as pointed out by Kamil. > Substr, > as Sara has

Re: [PHP-DEV] Introduce str_left/right In 8.1

On Wed, 23 Jun 2021 at 15:15, Hamza Ahmad wrote: > Hello Internals, > > Since feature freeze for 8.1 is approaching, I want to request two useful > string functions that exist in various languages-especially those that run > on web servers and used in databases. These are respectively `left();`

[PHP-DEV] [RFC] Deprecate boolean to string coercion

Hello Internals, With Ilija we are proposing a short RFC to deprecate coercion from bool to string: https://wiki.php.net/rfc/deprecate-boolean-string-coercion As this is the final day for any RFC to be even able to land in PHP 8.1 the voting is expected to start in two weeks on the 6th of July.

Re: [PHP-DEV] [VOTE] Pure intersection types

On Thu, 3 Jun 2021 at 20:31, G. P. B. wrote: > Hello internals > > I've opened the vote for the "Pure intersection types" RFC: > https://wiki.php.net/rfc/pure-intersection-types > > It will run for 2 weeks and end on the 17th of June 2021 > > Best regards,

[PHP-DEV] [VOTE] Pure intersection types

Hello internals I've opened the vote for the "Pure intersection types" RFC: https://wiki.php.net/rfc/pure-intersection-types It will run for 2 weeks and end on the 17th of June 2021 Best regards, George P. Banyard

Re: [PHP-DEV] json_encode indent parameter

On Thu, 3 Jun 2021 at 11:49, Timon de Groot wrote: > On 3-6-2021 10:00, Jordi Boggiano wrote: > > I agree, but I'd make it accept a string|int much like JSON.stringify > > does, because that way you let people pass in tabs too, or "" if > > that's how you want your JSON indented.. > > I like

Re: [PHP-DEV] [RFC] Pure intersection types

On Mon, 31 May 2021 at 16:09, G. P. B. wrote: > Hello, > > It has been two weeks since my last email and the only thing which has > come up are the tokenizer changes pointed out by Tyson. > To preserve BC I've aliased T_AMPERSAND with > T_AMPERSAND_FOLLOWED_BY_VAR_OR_VAR

Re: [PHP-DEV] [RFC] Pure intersection types

Hello, It has been two weeks since my last email and the only thing which has come up are the tokenizer changes pointed out by Tyson. To preserve BC I've aliased T_AMPERSAND with T_AMPERSAND_FOLLOWED_BY_VAR_OR_VARARG This is also reflected in the RFC:

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

On Tue, 25 May 2021 at 21:10, Calvin Buckley wrote: > I did some additional research and seemed to have decent luck with > slamming a construct like this after the includes: > > #define emalloc malloc > #define erealloc realloc > #define ecalloc calloc > #define estrdup strdup > #define

Re: [PHP-DEV] [RFC] [Vote] Final constants

On Wed, 19 May 2021 at 09:03, Máté Kocsis wrote: > Hi Internals, > > 2 weeks of discussion period has passed, so I'm opening the vote. RFC link: > https://wiki.php.net/rfc/final_class_const, previous threads: > https://externals.io/message/114066, https://externals.io/message/114273 > > The vote

Re: [PHP-DEV] [RFC] Pure intersection types

On Mon, 17 May 2021 at 15:17, Larry Garfield wrote: > On the reflection front, am I correct that we'd end up with: > > abstract ReflectionType > -- ReflectionNamedType (single type) > -- ReflectionUnionType (basically an array of named types) > -- ReflectionIntersectionType (basically an array

Re: [PHP-DEV] [RFC] Pure intersection types

Hello internals, As we are getting closer to feature freeze I want to move this proposal forward. The RFC is now also on the wiki: https://wiki.php.net/rfc/pure-intersection-types Composite types are left out of scope as it seems they should be handled with grouping (e.g. (A) | C ) and not

Re: [PHP-DEV] PR for minor bugfix in compact()

On Wed, 28 Apr 2021 at 12:12, David Gebler wrote: > Hi internals, > I've opened a PR to cause compact() to throw a TypeError if its parameters > are not valid, which I consider to be a fix for what is effectively a bug > whereby logical errors in user code can be silently swallowed. > > GPB has

Re: [PHP-DEV] [VOTE] Deprecate implicit non-integer-compatible float to int conversions

On Thu, 1 Apr 2021 at 12:39, G. P. B. wrote: > Hello internals, > > It's been a couple of weeks and no further comments have been made as such > voting is now open: > > https://wiki.php.net/rfc/implicit-float-int-deprecate > > It will run for two weeks until the 14th

Re: [PHP-DEV] [RFC] Pure intersection types

On Tue, 23 Mar 2021 at 19:45, Matthew Brown wrote: > On Tue, 23 Mar 2021 at 05:32, G. P. B. wrote: > >> I'm calling this proposal pure intersection types as there would be no >> possibility of mixing intersection and union types, I'm leaving this as a >> future scop

[PHP-DEV] [VOTE] Deprecate implicit non-integer-compatible float to int conversions

Hello internals, It's been a couple of weeks and no further comments have been made as such voting is now open: https://wiki.php.net/rfc/implicit-float-int-deprecate It will run for two weeks until the 14th of April 2021. Best regards, George P. Banyard

Re: [PHP-DEV] Changes to Git commit workflow

On Tue, 30 Mar 2021 at 14:34, Mike Schinkel wrote: > > > > On Mar 30, 2021, at 8:29 AM, Jakub Zelenka wrote: > > > > > > > > On Tue, Mar 30, 2021 at 1:21 PM Jakub Zelenka bu...@php.net>> wrote: > > > > > > On Tue, Mar 30, 2021 at 12:47 PM Mike Schinkel > wrote: > >

Re: [PHP-DEV] Changes to Git commit workflow

On Mon, 29 Mar 2021 at 12:50, Max Semenik wrote: > On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote: > > > changes should be pushed directly to GitHub rather than to git.php.net. > > > Would it also make sense if direct pushes (bypassing the pull requests > system) were disallowed completely?

Re: [PHP-DEV] [RFC] Pure intersection types

On Tue, 23 Mar 2021 at 13:14, Larry Garfield wrote: > On Tue, Mar 23, 2021, at 4:32 AM, G. P. B. wrote: > > Greetings internals, > > > > I'm presenting a new RFC to add support for pure intersection types to > PHP. > > > > An intersection type A

[PHP-DEV] [RFC] Pure intersection types

Greetings internals, I'm presenting a new RFC to add support for pure intersection types to PHP. An intersection type A means that the value must be of type A and of type B at the same time. I'm calling this proposal pure intersection types as there would be no possibility of mixing

Re: [PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

On Thu, 4 Mar 2021 at 17:49, G. P. B. wrote: > On Thu, 4 Mar 2021 at 13:23, Andreas Leathley wrote: > >> On 04.03.21 14:07, G. P. B. wrote: >> > This new version of the RFC can be found on the wiki: [2] >> > https://wiki.php.net/rfc/implicit-float-int-deprecate >

Re: [PHP-DEV] [VOTE] Fibers

On Mon, 22 Mar 2021 at 16:20, G. P. B. wrote: > On Mon, 22 Mar 2021 at 16:01, Guilliam Xavier > wrote: > >> On Mon, Mar 22, 2021 at 4:38 PM Levi Morrison < >> levi.morri...@datadoghq.com> >> wrote: >> >> > On Mon, Mar 22, 2021 at 9:13 AM Guilliam

Re: [PHP-DEV] [VOTE] Fibers

On Mon, 22 Mar 2021 at 16:01, Guilliam Xavier wrote: > On Mon, Mar 22, 2021 at 4:38 PM Levi Morrison > > wrote: > > > On Mon, Mar 22, 2021 at 9:13 AM Guilliam Xavier > > wrote: > > > > > > On Sat, Mar 20, 2021 at 3:06 PM Aaron Piotrowski > > wrote: > > >> > > >> > > >> > On Mar 19, 2021, at

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

On Thu, 25 Feb 2021 at 20:26, Nikita Popov wrote: > Hi internals, > > The question of namespaces in the stdlib has been coming up a lot recently, > so I'd like to present my own stab at resolving this question: > > https://wiki.php.net/rfc/namespaces_in_bundled_extensions > > Relative to a

Re: [PHP-DEV] [VOTE] Fibers

On Fri, 12 Mar 2021 at 04:06, 韩天峰 wrote: > HiDan, > > > We have no commercial purpose on the swoole open source project.This > is a purely technical project. > If possible, we can remove the name of swoole, contribute the source code > of swoole-src to php-src, and transfer the copyright. > Here

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On Thu, 4 Mar 2021 at 22:05, Rowan Tommins wrote: > On 04/03/2021 14:08, G. P. B. wrote: > > This new RFC which I'm proposing is to extend the capability of the error > > control operator @ to not just suppress diagnostic messages but also > > exceptions. > > It can c

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

As Rowan has addressed your first points, I'll skip them but will add a code example to clarify in the RFC. On Fri, 5 Mar 2021 at 04:26, Mike Schinkel wrote: > > This proposal on it's own would not be sufficient to trigger such a > change > > for extensions but in combination with another

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On Thu, 4 Mar 2021 at 21:53, Christoph M. Becker wrote: > On 04.03.2021 at 18:46, G. P. B. wrote: > > > On Thu, 4 Mar 2021 at 16:06, AllenJB wrote: > > > >> On a related note I dislike "documentation burden" as an argument > >> against imp

Re: [PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

On Thu, 4 Mar 2021 at 13:23, Andreas Leathley wrote: > On 04.03.21 14:07, G. P. B. wrote: > > This new version of the RFC can be found on the wiki: [2] > > https://wiki.php.net/rfc/implicit-float-int-deprecate > > I like the RFC, but I think the diagnostic messages will be

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

On Thu, 4 Mar 2021 at 16:06, AllenJB wrote: > > On 04/03/2021 14:08, G. P. B. wrote: > > Hello internals, > > > > This new RFC which I'm proposing is to extend the capability of the error > > control operator @ to not just suppress diagnostic messages but a

[PHP-DEV] [RFC] Extend error control operator to suppress exceptions

Hello internals, This new RFC which I'm proposing is to extend the capability of the error control operator @ to not just suppress diagnostic messages but also exceptions. It can currently be found on GitHub: [1] https://github.com/Girgias/error-control-operator-exceptions-rfc The main

[PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

Hello internals, This is a follow-up on the previous thread [1] about my RFC tackling implicit float to int conversion. It is now slightly larger in scope as it also pertains to what I call "non compatible integer floating numbers". This new version of the RFC can be found on the wiki: [2]

Re: [PHP-DEV] Deprecate debug_zval_dump?

On Sat, 27 Feb 2021 at 14:00, Rowan Tommins wrote: > Hi all, > > I would like to propose we formally deprecate the function debug_zval_dump > and remove it in PHP 9.0. > > This function is mostly similar to var_dump, with the additional ability > to output the refcount of a variable. This has

Re: [PHP-DEV] Requesting RFC karma for your wiki account.

On Thu, 11 Feb 2021 at 02:03, Russell Stuart < russell+lists.php@stuart.id.au> wrote: > I'm created a branch to php-src that makes pdo_firebird::getColumnMeta() > return "native_type" in addition to "pdo_type". It also fixes a bug in > the current getColumnMeta() (of the SIG_SEGV variety),

[PHP-DEV] Interaction between finally blocks and exit()

Greetings internals, While working on rewriting the PHP docs about errors and error handling [1] I came across a change of behaviour in an edge case of an edge case. finally blocks are meant to be always executed regardless that an Exception has been thrown or not, which it does, however a call

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

On Thu, 4 Feb 2021 at 17:55, Benjamin Morel wrote: > On Thu, 4 Feb 2021 at 17:05, G. P. B. wrote: > >> Greetings internal, >> >> I'm proposing a new RFC which would warn when an implicit conversion >> from float to int occurs. >> >> The draf

[PHP-DEV] [RFC] Warning for implicit float to int conversions

Greetings internal, I'm proposing a new RFC which would warn when an implicit conversion from float to int occurs. The draft is currently located on GitHub: https://github.com/Girgias/float-int-warning/ for ease of commenting/providing changes to it. The official discussion phase wouldn't start

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

On Mon, 25 Jan 2021 at 16:25, Christian Schneider wrote: > Am 25.01.2021 um 16:59 schrieb G. P. B. : > > The BC break is totally minimal as it's a one line of code that needs to > be added (and for all intent and purposes should already be done). > > That does not change the fa

Re: [PHP-DEV] [RFC] Enumerations, Round 2

On Mon, 25 Jan 2021 at 02:29, Larry Garfield wrote: > Aside from some nitpicking around reflection and possibly fiddling with > the naming of "Scalar Enum" et al, we're closing in on the final version. > It will probably go to a vote in the not too distant future. > > --Larry Garfield > > -- >

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

On Mon, 25 Jan 2021 at 15:41, Christian Schneider wrote: > Am 21.01.2021 um 23:46 schrieb Kamil Tekiela : > > In fact, I don't really see this as a major breaking change. If any > project > > really needs the mysqli errors silenced then they can just set the error > > mode back to OFF. The

Re: [PHP-DEV] #[Deprecated] Attribute

On Sat, 19 Dec 2020 at 10:19, Benjamin Eberlei wrote: > Hi internals, > > I have updated the RFC for a #[Deprecated] attribute that wasn't completed > for PHP 8.0 due to time constraints and I am able to restart the discussion > now. > > https://wiki.php.net/rfc/deprecated_attribute > > The

Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals

On Sun, 10 Jan 2021 at 00:33, Larry Garfield wrote: > On Sun, Jan 3, 2021, at 11:29 AM, Olle Härstedt wrote: > > > > I'll disagree slightly. A language feature should introduce more > power than > > > it does complexity. Not everything *can* be made absolutely simple, > but the > > > power it

Re: [PHP-DEV] Re: Moving from SVN to git - finally!

On Wed, 30 Dec 2020 at 01:06, Tiffany Taylor wrote: > On Tue, Dec 29, 2020 at 4:44 PM  Good Guy  wrote: > > > On 29/12/2020 20:01, Tiffany Taylor wrote: > > > On Tue, Dec 29, 2020, 1:11 PM  Good Guy  > > > wrote: > > > > > > On 29/12/2020 18:34, Andreas Heigl

Re: [PHP-DEV] Re: Moving from SVN to git - finally!

Just for information I'm working on establishing a revcheck from git, I'm expecting this to be done within the next couple of days as last year I was playing around making doc.php.net a static website built via GitLab CI. This would also take care of mapping SVN revision to git commits, such a

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

On Tue, 22 Dec 2020 at 16:05, tyson andre wrote: > Hi Marco, > > >Hey Tyson, > > > > I know I'm being stubborn, but we have namespaces, but also an "old > guard" that doesn't understand its own programming language 路‍♀️ > > I assume it's a case of not liking them or assuming others wouldn't like

Re: [PHP-DEV] Follow up on Octal literal RFC

On Mon, 21 Dec 2020 at 19:36, G. P. B. wrote: > Now, onto the weird special case, which looks like a bug in the > implementation of base_convert() as > var_dump(base_convert('O', 8, 10)); > Will emit the following deprecation warning (but only if the starting base > is 8): > D

[PHP-DEV] Follow up on Octal literal RFC

Hello internals, The implementation for the RFC still hasn't landed due to some helpful remarks made by Tyson Andre. The issues lie not with the core functionality itself but how to amend extensions which have a notion of numeric string literals. I have added test cases for the extension but

Re: [PHP-DEV] PHP 8 incompatible change documentation issues

Please use the documentation list to talk about documentation issues and not the internal list. On Thu, 3 Dec 2020 at 14:18, Thomas Hruska wrote: > https://www.php.net/manual/en/migration80.incompatible.php > > Under the "String to Number Comparison" section of the migration guide, > there's

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

On Wed, 2 Dec 2020 at 17:24, Florian Stascheck wrote: > Hello! > > With PHP8 released and the named arguments RFC being implemented, there's > now an inconsistency in how the spread operator works. > > Historically, the spread operator was first used in PHP 5.6 for arguments: > > function

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

On Tue, 1 Dec 2020 at 18:35, Paul Crovella wrote: > On Tue, Dec 1, 2020 at 10:23 AM G. P. B. wrote: > > > > On Tue, 1 Dec 2020 at 18:07, Paul Crovella > wrote: > >> > >> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker > wrote: > >> &

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

On Tue, 1 Dec 2020 at 18:07, Paul Crovella wrote: > On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker > wrote: > > > > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote: > > > > > Am 01.12.20 um 18:24 schrieb Christoph M. Becker: > > >> > > >>> In PHP 7, this returns FALSE: > > >>> > >

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

On Tue, 1 Dec 2020 at 17:46, G. P. B. wrote: > On Tue, 1 Dec 2020 at 17:45, Paul Crovella > wrote: > >> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker >> wrote: >> > >> > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote: >> > >>

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

On Tue, 1 Dec 2020 at 17:45, Paul Crovella wrote: > On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker > wrote: > > > > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote: > > > > > PHP 8 is stricter in checking input data then PHP 7. This is good but > > > has some side effects for

Re: [PHP-DEV] Thank you to JetBrains (PHP 8 Announcement page)

On Fri, 27 Nov 2020 at 16:42, Benjamin Morel wrote: > I really like this page as well! It will definitely help improve PHP's > reputation and adoption. > > I'd like to suggest a couple improvements, though: > > 1/ Match expression: > > The new match is similar to switch and has the following

Re: [PHP-DEV] ZEND_ENGINE_4

On Thu, 26 Nov 2020 at 02:42, Sara Golemon wrote: > Maybe just a wee bit late to ask this question, but shouldn't we have long > since changed `#define ZEND_ENGINE_3` to `#degine ZEND_ENGINE_4` ? > > Was that deliberate since (unlike with 4->5 and 5->7) the engine's API > surface area hasn't

Re: [PHP-DEV][RFC][VOTE] Explicit octal integer literal notation

On Wed, 11 Nov 2020 at 12:25, G. P. B. wrote: > Greetings Internals, > > The vote for the "Explicit octal integer literal notation" RFC is now > open. > https://wiki.php.net/rfc/explicit_octal_notation > > It will last two [2] weeks, until 2020-11-25. > > Bes

<    1   2   3   4   >