[PHP-DEV] Renaming on of the XML opaque objects for consistency

Greetings internals, I know this is *literally* hours before the GA tag, but I just realized that when introducing opaque objects during the resource to object conversion the XMLWriter and XMLParser extensions don't use the same casing as the classes are named XmlParser and XMLWriter Should we

Re: [PHP-DEV] Union `&` operator

On Sat, 14 Nov 2020 at 11:17, Eugene Sidelnyk wrote: > Levi will not have time for this. Who else do you suggest? > Please do NOT prompt someone to implement a feature for you for free. Many of us would like intersection types but it takes time to implement it. And as a reminder most people who

Re: [PHP-DEV] strict_types will be default at some moment?

On Wed, 11 Nov 2020 at 21:47, Rowan Tommins wrote: > On 11/11/2020 20:20, David Rodrigues wrote: > > I have been asked by a friend if declare(strict_types=1) will be applied > by > > default for some version of PHP, like 9.x or will it be always required > by > > all scripts forever. Someone can

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

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. Best regards, George P. Banyard

Re: [PHP-DEV][RFC] Add support for explicit octal notation for integer literals

Hello internals, As the 2 week discussion period has passed I intend to open voting on Tuesday the 10th of November. I did a bit of rewording on the RFC but it is fundamentally identical: https://wiki.php.net/rfc/explicit_octal_notation Any remaining concerns, clarifications and/or questions

Re: [PHP-DEV][RFC] Add support for explicit octal notation for integer literals

On Wed, 21 Oct 2020 at 16:56, Eugene Sidelnyk wrote: > What is the practical use case for this. I think it will make code a bit > more confusing > > On Wed, Oct 21, 2020, 5:59 PM G. P. B. wrote: > >> Hello internals, >> >> A rather short RFC about adding supp

Re: [PHP-DEV] Nullsafe

On Tue, 3 Nov 2020 at 19:08, G. P. B. wrote: > On Tue, 3 Nov 2020 at 19:05, Eugene Sidelnyk wrote: > >> Null value by itself was invented to indicate lack of data. >> But we can't just use it instead of objects, because of how it works. >> We need to create a bo

Re: [PHP-DEV] Nullsafe

On Tue, 3 Nov 2020 at 16:48, Benjamin Morel wrote: > On Tue, 3 Nov 2020 at 17:38, Eugene Sidelnyk wrote: > > > I am wondering why don't we use ordinary `->` operator with safe null > > handling? > Implicit nullable is terrible, moreover I don't see why users should return null values more

Re: [PHP-DEV] Hello

On Thu, 22 Oct 2020 at 10:11, Andreas Bittner wrote: > Hello everyone > > I've been a reader of internals for some years and would like to join > the round. > > Unfortunately I have no experience implementing changes to the PHP > source itself. I hope to find the time to work my way into php-src

[PHP-DEV][RFC] Add support for explicit octal notation for integer literals

Hello internals, A rather short RFC about adding support for the "0o" prefix for octal integers. https://wiki.php.net/rfc/explicit_octal_notation Surprisingly PHP already accepts the prefix within octdec() and base_convert(). I have hopefully covered all the cases where this may apply but if

Re: [PHP-DEV] Re: want an Object-oriented interface for HashContext

On Mon, 12 Oct 2020 at 15:01, Kingsquare.nl - Robin Speekenbrink < ro...@kingsquare.nl> wrote: > Op ma 12 okt. 2020 om 14:55 schreef Christoph M. Becker >: > > > On 12.10.2020 at 13:49, Hans Henrik Bergan wrote: > > > > > something like > > > > > > $result = (new > >

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

On Tue, 6 Oct 2020 at 12:20, Brent Roose wrote: > The point of short closures, regardless of single line or multi line, is > addressed (and agreed upon by the RFC votes) in the first pararaph of the > RFC [1]. I'm not sure if I can add anything useful rather than saying "it's > nice to be able

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

On Tue, 6 Oct 2020 at 11:28, G. P. B. wrote: > First, can you please bottom-post and not top-post. > > On Tue, 6 Oct 2020 at 09:53, Brent Roose wrote: > >> Hi internals >> >> The reason multi-line short closures are so valued by userland devs is >> because th

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

First, can you please bottom-post and not top-post. On Tue, 6 Oct 2020 at 09:53, Brent Roose wrote: > Hi internals > > The reason multi-line short closures are so valued by userland devs is > because they are shorter to write and prettier to read. While some of us > might not agree on the

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

On Tue, 29 Sep 2020 at 13:44, Dik Takken wrote: > On 29-09-2020 14:17, Remi Collet wrote: > > I think parameter names (public API) still can change in next RC > > as named parameters are not yet widely used. > > How about warning promotions? My own impression is that we are 99% there > but not

Re: [PHP-DEV] Stubs in ext/ldap

On Thu, 17 Sep 2020 at 15:18, Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Le Thu, 17 Sep 2020 15:03:05 +0200, > "G. P. B." a écrit : > > A lot of the documentation is not up to date and will needs to be updated > > after > > ther

Re: [PHP-DEV] Stubs in ext/ldap

On Thu, 17 Sep 2020 at 14:53, Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Hello, > > After playing with phpstan and seeing their stubs for some LDAP functions > were > wrong, I noticed that documentation for LDAP functions and stubs in > ext/ldap/ldap.stub.php differs. > A lot

Re: [PHP-DEV] The case for transpiled generics

On Thu, 17 Sep 2020 at 13:33, Brent Roose wrote: > Hello internals > > Today I'd like to hear your thoughts on what might be a controversial > topic, though I think it's worth having this discussion. I want to make the > case for adding generic syntax, without actually enforing any additional >

Re: [PHP-DEV] Use PSR coding guidelines in php.net docs (instead of PEAR-CS)

On Fri, 4 Sep 2020 at 15:50, Tymoteusz Motylewski wrote: > Hi, > Right now (as stated here: http://doc.php.net/tutorial/style.php) the code > style used in PHP documentation is PEAR-CS > https://pear.php.net/manual/en/coding-standards.php > > The problem is that: > - PEAR-CS does not cover new

Re: [PHP-DEV] PDO fetch performance problems with many bind parameters

Just that you are aware the emails from both of you went to my spam folder. Back to the matter, this is the correct list to email Dino, however could you open a pull request on GitHub for this change so that more eyes (and especially eyes from people which know PDO) can have a look? Please

Re: [PHP-DEV] Allow sleep() to accept non-integer values

Apologies for the double email, my client did something funcky. On Thu, 20 Aug 2020 at 14:22, G. P. B. wrote: > On Thu, 20 Aug 2020 at 14:15, Michael Voříšek - ČVUT FEL < > voris...@fel.cvut.cz> wrote: > >> Hi everyone, >> >> thank you for your

Re: [PHP-DEV] Allow sleep() to accept non-integer values

On Thu, 20 Aug 2020 at 14:15, Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > Hi everyone, > > thank you for your comments, based on them, I fixed these: > > - usleep is now used as a fallback as well, if interrupted, remaining > time is measured using microtime, so return value is

Re: [PHP-DEV] Allow sleep() to accept non-integer values

On Tue, 11 Aug 2020 at 13:03, Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > > Another reason is that sleep(0.1); is silently accepted now (even with > strict types enabled), > > > > That appears to not be true: https://3v4l.org/7YbqX > > corrected, should be "without strict types

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

Hello internals, Although, 1 day later than meant to, I'm glad to announce the Saner Numeric String RFC has been accepted with 30 votes in favour and 4 votes against. The secondary implementation detail vote has failed with 2 votes in favour and 27 votes against. Best regards George P. Banyard

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

On Wed, 22 Jul 2020 at 13:39, Deleu wrote: > "Terrible" is the amount of humans having their lives taken by a pandemic. > This is at most slightly inconvenient for you. The aggressive tone in this > discussion is extremely unnecessary. > When the voted syntax is technically infeasible due to

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

On Thu, 16 Jul 2020 at 15:39, Marco Pivetta wrote: > Hey George, > > I really like this specific bit of the proposal: > > > And the various cases which currently emit an E_WARNING will be > promoted to TypeErrors. > > I really do not like these particular horrible behaviors of the language >

[PHP-DEV] [RFC] [VOTE] Saner numeric strings

Hello internals, I've opened voting for the Saner Numeric strings RFC: https://wiki.php.net/rfc/saner-numeric-strings This will last 2 weeks until the 30th of July Best regards George P. Banyard

Re: [PHP-DEV][RFC] Saner numeric strings

Hello internals, Apologies again for the delay, I was pointed out a sort of inconsistency between arithmetic/bitwise ops and type declarations. I've tried to address this in the RFC by promoting all current warnings to TypeErrors: https://wiki.php.net/rfc/saner-numeric-strings Please have a

Re: [PHP-DEV][RFC] Saner numeric strings

Good afternoon Internals, I rewrote the RFC to improve clarity but the content is mostly identical with one small change is that the warning change from 'Illegal offset type' to 'String cast occurred' for string offsets such as '5.5' will be a secondary implementation vote as it adds some

Re: [PHP-DEV][RFC] Saner numeric strings

On Wed, 1 Jul 2020 at 18:44, Rowan Tommins wrote: > Hi George, > > On Wed, 1 Jul 2020 at 15:26, G. P. B. wrote: > >> >>2. Emit the E_WARNING "Illegal string offset" and evaluate to 0 for >>offsets like '2str', and emit the E_WARNING "String

Re: [PHP-DEV][RFC] Saner numeric strings

Hello again, While reviewing the implementation Nikita spotted a peculiar behaviour that PHP currently has in regards to string offsets. The offset is validated using the is_numeric_string but integer representation of it is computed using an explicit int cast, this is what leads to the E_NOTICE

Re: [PHP-DEV][RFC] Saner numeric strings

I've added a test case just to ensure that casting of leading numeric strings yields the previous behaviour and have added this to the BC Break section of the RFC: https://wiki.php.net/rfc/saner-numeric-strings Any other feedback or questions are welcomed. George P. Banyard

Re: [PHP-DEV][RFC] Saner numeric strings

On Mon, 29 Jun 2020 at 14:53, Claude Pache wrote: > > > Le 29 juin 2020 à 12:30, G. P. B. a écrit : > > > > Greetings internal, > > > > While reviving the "Permit trailing whitespace in numeric strings" RFC > [1] > > I didn't see Niki

[PHP-DEV][RFC] Saner numeric strings

Greetings internal, While reviving the "Permit trailing whitespace in numeric strings" RFC [1] I didn't see Nikita's comment on Andrea's original PR which commented on the fact that we should get rid of the "leading-numeric string" concept. Therefore, mostly due to time constraints, I've merge

Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Hello Andrea, Benjamin, and others, Better error messages are obviously better than just replacing the name of the token, however this argument is saying that because this isn't perfect let's do nothing. I wasn't aware that Rowan had made good progress on his patch, however, if this patch needs

[PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Hello internals, As the two week discussion period has elapsed the vote is now open. We did acknowledge the suggestion of dropping the token name from the error message directly, but in our opinion this is an orthogonal change to the one proposed, and has the risk of not landing in PHP 8.0. The

[PHP-DEV] [RFC] Permit trailing whitespace in numeric strings (again)

Greetings internals, I want to bring back the following RFC, written by Andrea Faulds, back to the discussion table: https://wiki.php.net/rfc/trailing_whitespace_numerics As she doesn't have time to move forward with it she allowed me to take it over. I've rebased her patch onto master in the

Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors

On Tue, 16 Jun 2020 at 02:35, Benas IML wrote: > Hey internals, > > I am proposing to allow void return type for constructors/destructors. > Note, > that this is an **optional** and cosmetic-only addition! All of the > reasoning > is in the RFC. > > RFC:

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

On Mon, 15 Jun 2020 at 20:05, Lynn wrote: > On Mon, Jun 15, 2020 at 7:46 PM Alain D D Williams > wrote: > > > It is very easy to take offence when none is meant at all. One needs to > > look at intent. > > > > Hi, > > I'm going to disagree here. It's not about intent, it's about impact. You >

[PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Greetings PHP internals, Kalle Sommer Nielsen and myself are proposing to rename the T_PAAMAYIM_NEKUDOTAYIM token into the already existing T_DOUBLE_COLON alias, T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON. The RFC is located here:

Re: [PHP-DEV] What to do with ext/imap?

On Mon, 8 Jun 2020 at 18:15, Christoph M. Becker wrote: > Hi all, > > I'm wondering what to do with ext/imap, which uses libc-client which had > its latest release (2007f) in 2011. There is a respective feature > request in the bug tracker () where some > ideas have

Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode

On Fri, 22 May 2020 at 18:09, Katie Volz wrote: > Hello internals, > > I want to start a discussion on an RFC to add a declare() statement to > convert all errors triggered within a file to exceptions. > > Currently, the only way to handle notices/warnings in an exception-like > manner is via

Re: [PHP-DEV] [RFC] Add CMS Support

On Tue, 19 May 2020 at 11:44, Eliot Lear wrote: > Dan, thanks. Please see below. > > On 18.05.20 13:49, Dan Ackroyd wrote: > >> Returns TRUE on success and FALSE on failure. > > Have you considered using an exception for failures? > > > > First, having a cryptographic function fail is bad

Re: [PHP-DEV] [RFC] Guard statement

On Sat, 16 May 2020 at 11:14, Pavel Patapau wrote: > Hello everyone, > > I want to propose new syntax addition - guard statement, that executes > code only if expression equals false and must contain control-flow > changing code, and written a respective RFC: > >

Re: [PHP-DEV] Re: PR #5251 adds support for CMS (RFC5662)

On Mon, 11 May 2020 at 12:45, Christoph M. Becker wrote: > On 11.05.2020 at 11:59, Eliot Lear wrote: > > > Hi everyone, > > > > I am new to the PHP development process, so please forgive me if I have > > this wrong. > > > > In PR #5251[1] I’ve created OpenSSL CMS functions that are nearly direct

Re: [PHP-DEV] [RFC] Keep type of reference params

On Fri, 8 May 2020 at 13:04, Thomas Gutbier wrote: > Am 08.05.2020 um 12:37 schrieb G. P. B.: > > I think everyone can agree this is useful. But the issue here is the > > implementation. Because from what I know PHP's references are aspecial > > kind of pain in the engin

Re: [PHP-DEV] [RFC] Keep type of reference params

On Mon, 4 May 2020 at 10:54, Manuel Canga wrote: > Hi internals, > I would like to present a possible new RFC( "keep type of reference > params" ) for your > consideration. > [...] > The result of this code is a warning( in count line ) because of $array is > a string. > > However, I think it

Re: [PHP-DEV] Update coding standards wrt. C99?

On Wed, 6 May 2020 at 12:20, Xinchen Hui wrote: > mixing declarations and codes sometimes brings unexpected > varaibles overriden and hard to debugging. > > thanks > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ In a perfect world we would be able to enable the -Wshadow GCC

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

Hello everyone, We've updated the RFC [1] by rewriting it in part and trying to add more details /context and trying to address some other concerns which came up. Hoping for some more feedback before planning on moving this to a vote. Best regards George P. Banyard [1]

Re: [PHP-DEV] printf() improvements

On Wed, 22 Apr 2020 at 15:25, Nikita Popov wrote: > Hi internals, > > I'd like to make two improvements to the printf() functionality exposed by > PHP (also affecting other variations like sprintf, vprintf, etc.) These > improvements are motivated by >

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

On Wed, 15 Apr 2020 at 22:27, Derick Rethans wrote: > On 15 April 2020 20:36:25 BST, "G. P. B." > wrote: > >On Wed, 15 Apr 2020 at 15:51, Derick Rethans wrote: > > > >> On Wed, 15 Apr 2020, Michał Brzuchalski wrote: > >> > >>

Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast

Hello all, We've updated the implementation [1] and RFC [2] to provide a temporary INI setting which will emit a warning every time a locale-aware float to string conversation would have been done in PHP 7. It's current name debug_local_sensitive_float_casts is also up to debate and will be voted

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

On Wed, 15 Apr 2020 at 19:24, Andrea Faulds wrote: > Hi, > > Michał Brzuchalski wrote: > > Hi Marcio, > > > > śr., 15 kwi 2020 o 18:39 Marcio Almada > napisał(a): > > > >> Even though I'm fond to the idea of languages having the official > >> stdlib contained > >> into a single space, there

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

On Wed, 15 Apr 2020 at 18:39, Marcio Almada wrote: > > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard and it's > > purpose > > is nothing more like to

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

On Wed, 15 Apr 2020 at 15:51, Derick Rethans wrote: > On Wed, 15 Apr 2020, Michał Brzuchalski wrote: > > > Hi internals, > > > > I hope you're doing well. > > > > I'd like to announce the PHP Namespace in core RFC for discussion. > > The RFC is authored by me together with George Peter Banyard

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

On Wed, 15 Apr 2020 at 14:29, Michał Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is

Re: [PHP-DEV] [DISCUSSION] Match expression

On Sun, 12 Apr 2020 at 02:16, Ilija Tovilo wrote: > Hi internals > > I'd like to announce the match expression RFC that replaces the switch > expression RFC I announced a few weeks ago. > New: https://wiki.php.net/rfc/match_expression > Old: https://wiki.php.net/rfc/switch_expression > > Due to

Re: [PHP-DEV] [VOTE] throw expression

On Sun, 5 Apr 2020 at 12:03, Ilija Tovilo wrote: > Hi internals, > > I hope you're doing well. > > I have opened voting for the throw expression RFC. > https://wiki.php.net/rfc/throw_expression > > Voting closes on April 19th, 2020. > > Regards, > Ilija > > -- > PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] Stricter type-checks for arithmetic/bitwise operators

On Thu, 2 Apr 2020 at 10:14, Nikita Popov wrote: > Hi internals, > > I would like to propose making the use of arithmetic/bitwise operators on > arrays, resources and (non-overloaded) objects a TypeError exception: > > https://wiki.php.net/rfc/arithmetic_operator_type_checks > > This is inspired

Re: [PHP-DEV] [RFC] switch expression

On Sun, 29 Mar 2020 at 23:54, Stanislav Malyshev wrote: > Hi! > > > My recommendation would be to just borrow Rust's keyword: > > > > $result = match ($var) { > > $expression => $expression; > > $expression => $expression; > > $expression => $expression; > > default => $expression; > > }

Re: [PHP-DEV] [RFC] switch expression

On Sun, 29 Mar 2020 at 23:04, Ilija Tovilo wrote: > > Having two syntaxes for one keyword is not a good idea, > > We're already doing that. What about classes vs anonymous objects? > Functions vs closures? > They're using the same keywords. There's no confusion. > > Ilija > > -- > PHP Internals

Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast

On Tue, 24 Mar 2020 at 11:03, Lynn wrote: > Hi, > > This is a great RFC! Just one minor thing. > > > Outputting floats as strings in locales which change the decimal > separator will have a slightly different output. In our opinion, the > backward compatibility break won't be serious in practice

Re: [PHP-DEV] [Discussion] Promoting declare failure notices to exceptions?

On Sat, 14 Mar 2020 at 21:19, Mark Randall wrote: > Greetings, > > I have created a PR that will throw exceptions when using define() > with invalid types or when trying to redefine. > > Trying to redefine a constant or define a bad constant would throw a > ValueError on the name parameter,

Re: [PHP-DEV] Changing the default PDO error mode

On Sat, 14 Mar 2020 at 22:10, Larry Garfield wrote: > On Sat, Mar 14, 2020, at 10:40 AM, AllenJB wrote: > > Hi all, > > > > A regular problem that new users run into is error handling with PDO. > > The current default error mode for PDO is "silent". This leads to the > > situation where code

Re: [PHP-DEV] Associated Arrays as function parameters

On Sat, 14 Mar 2020 at 15:43, Midori Koçak wrote: > Dear Internals, > > I would like to as you a question. I know that it is possible to use an > array to function parameters like: function(...array); But this method is > not working when the array is associative. > > Would not be fine if an

Re: [PHP-DEV] New PCRE function

On Wed, 19 Feb 2020 at 18:15, Mike Schinkel wrote: > > On Feb 19, 2020, at 12:10 PM, Rowan Tommins > wrote: > > > >>> On Wed, Feb 19, 2020 at 4:20 PM David Rodrigues < > david.pro...@gmail.com> > >>> wrote: > >>> > Maybe you can set all this messages as lowercase? That way we can use > it

Re: [PHP-DEV] [RFC] get_debug_type

On Mon, 17 Feb 2020 at 00:25, Mike Schinkel wrote: > > On Feb 16, 2020, at 8:15 AM, Mark Randall wrote: > > The name is up for debate. > > Cool. > > Though still not exactly sure where you are headed with it since there are > few detailed and no code examples the first name that comes to mind

Re: [PHP-DEV] [RFC] Userspace operator overloading

On Sat, 15 Feb 2020 at 23:06, wrote: > Hi internals, > > based on the discussions here (https://externals.io/message/108300) and > here > (https://github.com/php/php-src/pull/5156), I have created a proper RFC > for > userspace operator overloading: >

Re: [PHP-DEV] Proposal for a new basic function: str_contains

On Fri, 14 Feb 2020 at 10:58, Aegir Leet wrote: > I generally like the idea, but it seems many (most?) real-world > implementations actually use mb_strpos() !== false by default. > > >

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

On Mon, 10 Feb 2020 at 22:50, Tom Van Looy via internals < internals@lists.php.net> wrote: > Hi > > While in some environments the use of MD5 and SHA1 are still acceptable for > some use cases like file integrity verification etc. the use of these > algorithms should be discouraged and not be

Re: [PHP-DEV] A Hacker's Guide - Obsolete

On Thu, 23 Jan 2020 at 13:07, Daniel Martín Spiridione < daniel.spiridi...@gmail.com> wrote: > Hi interns. The official PHP.net documentation of the "PHP at the Core: A > Hacker's Guide" section (https://www.php.net/manual/en/internals2.php) is > obsolete. > > In that sense Python has good

Re: [PHP-DEV] [RFC] Allow ::class on objects

On Tue, 14 Jan 2020 at 19:05, Ralph Schindler wrote: > > > > just return $string, to be consistent with usual behavior of > > "::CONST_NAME", which allows objects and class names on the left hand > side. > > Having given it more thought, it seems like like $string::class should > be more aligned

Re: [PHP-DEV] Bump required libcurl version to 7.17.1

On Sun, 12 Jan 2020 at 23:33, Levi Morrison via internals < internals@lists.php.net> wrote: > On Sat, Jan 11, 2020 at 4:57 AM Olumide Samson > wrote: > > > > Why not the most recent and stable version? > > > > I'm thinking modern version has many bugs fixed and many vulnerabilities > > fixed,

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

On Wed, 8 Jan 2020 at 13:22, Björn Larsson wrote: > Den 2020-01-07 kl. 21:57, skrev George Peter Banyard: > > Greetings internals, > > > > I would like your input on adding TypeError and ValueError exceptions > > to the count() function in respect to the Consistent type errors for > > internal

Re: [PHP-DEV] Ensure correct signatures for PHP magic methods

On Mon, 6 Jan 2020 at 10:29, Gabriel Caruso wrote: > Hello George > > On Mon, 6 Jan 2020 at 01:28, G. P. B. wrote: > >> On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso >> wrote: >> >>> Hello Internals, >>> >>> I have a PR proposing t

Re: [PHP-DEV] Ensure correct signatures for PHP magic methods

On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso wrote: > Hello Internals, > > I have a PR proposing to start checking the signatures for PHP magic > methods in the next major version of PHP: > https://github.com/php/php-src/pull/4177. The idea for this PR came from >

Re: [PHP-DEV] Changelog / upgrading notes for promoted warnings

On Thu, 19 Dec 2019, 21:17 Rowan Tommins, wrote: > Hi all, > > Earlier, I was writing an application-specific wrapper around the > password_hash function, and was surprised that it could return false, > rather than throwing an error. > > I then found this commit to master making it throw errors

Re: [PHP-DEV] GitHub RFC workflow

Morning Internals, To start, I find it ironic that the people claiming that having everything self host is better for accessibility when the exact day most of this discussion occurred I'd wager 99% of the mailing list subscribers weren't able to follow the discussion as there was an issue with

Re: [PHP-DEV] Make error_reporting=E_ALL the default

On Fri, 30 Aug 2019 at 11:45, Zeev Suraski wrote: > > > On 30 Aug 2019, at 12:33, Nikita Popov wrote: > > > > Hi internals, > > > > Relating to the recent discussions on undefined variables & co. One thing > > that is particularly annoying about the undefined variable case is that > our > >

Re: [PHP-DEV] Re: Call for participation: Annotating internal function argument and return types

On Mon, 26 Aug 2019 at 18:02, Ryan McCullagh wrote: > I would be happy to help annotate the functions from the extensions in the > Missing list. One question. Should we be using the documentation as the > source of truth for parameter types, and return values? > > No, the documentation is at

Re: [PHP-DEV] Elevating Errors: Helpers + Formatting

On Tue, 20 Aug 2019 at 20:05, Mark Randall wrote: > Greetings, > > A week or so ago, G.P.B. submitted a pull request that contained a > declare that would automatically elevate certain errors to Error > exceptions (https://github.com/php/php-src/pull/4549). > > As part of the discussion, Nikic

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019年8月20日(火) 16:47 Rowan Tommins : > On 20/08/2019 13:51, G. P. B. wrote: > >- I seriously don't appreciate that the RFC has been edited*WITHOUT* > my > > knowledge to add endorsement names on the counterargument to the RFC on > the > > RFC itself when the approp

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

Hello internals, This RFC has been declined with 56% in favour (30/54) and 44% against (24/54). Two side notes to this: - I seriously don't appreciate that the RFC has been edited *WITHOUT* my knowledge to add endorsement names on the counterargument to the RFC on the RFC itself when the

Re: [PHP-DEV] Removing old branches in php-src

Hello, I think the list compiled in the initial email done by *Gabriel Caruso* [1] is a good starting point. Copied here for reference. 15+ years old: - experimental/RETURN_REF - experimetnal/RETURN_REF_PATCH - experimental/pre_new_hash_func - experimental/zts_stdc_scanners -

[PHP-DEV] Removing old branches in php-src

Hello internal, It seems this topic already has been raised a year ago [1] but nothing has been done. So I would like to raise the issue again, there are a various of old and empty branches currently in git, would it be possible to remove them? Best regards George P. Banyard [1]

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

On Tue, 6 Aug 2019 at 19:25, Chase Peeler wrote: > > > On Tue, Aug 6, 2019 at 1:19 PM G. P. B. wrote: > >> >> >> >> On Tue, 6 Aug 2019 at 19:12, Rowan Collins >> wrote: >> >>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: >>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

On Tue, 6 Aug 2019 at 19:12, Rowan Collins wrote: > On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: > > > I'm not a voter, but, I have a question. If this fails, does that mean > the > > original RFC that passed is still in effect? > > > > > Yes, this is really ambiguous, and risks the

[PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

The voting for the "Deprecate short open tags, again" [1] RFC has begun. It is expected to last two (2) weeks until 2019-08-20. A counter argument to this RFC is available at https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags Best regards George P. Banyard [1]

[PHP-DEV] Re: Counterargument to Short Tags Deprecation (was: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2)

On Tue, 6 Aug 2019 at 00:50, Zeev Suraski wrote: > > > On Mon, Aug 5, 2019 at 10:05 PM G. P. B. wrote: > >> >> I'd prefer Dan's approach and having a seperate page linked at the top of >> the RFC. >> >> I'll start voting tomorrow and will link to your

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

On Mon, 5 Aug 2019, 20:47 Zeev Suraski, wrote: > As we head closer to the vote - and in light of what I said towards the end > of my message in https://externals.io/message/106256#106278, as well as > the > points Dan articulated regarding the current issue of negative feedback not > getting the

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

On Thu, 25 Jul 2019 at 14:32, Nikita Popov wrote: > On Wed, Dec 6, 2017 at 8:49 PM Nikita Popov wrote: > > > Hi internals, > > > > I'd like propose optional support for explicitly marking by-reference > > argument passing at the call-site, in addition to the declaration-site: > > > >

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev wrote: > Hi! > > > Due to the controversy after the initial vote on the Deprecate PHP's > Short > > Open Tag RFC [1] here is a new RFC to deprecate them written with the > help > > of Nikita Popov . > > Could you please explain what has changed

[PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hello internals, Due to the controversy after the initial vote on the Deprecate PHP's Short Open Tag RFC [1] here is a new RFC to deprecate them written with the help of Nikita Popov . This RFC is targeting PHP 7.4 and has an exemption to land after the feature freeze granted by the Release

Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

On Tue, 16 Jul 2019 at 17:00, Zeev Suraski wrote: > On Tue, Jul 16, 2019 at 7:34 AM G. P. B. wrote: > >> The RFC process establishes a consensus when 2/3 of the voters agree, >> which is currently the case. >> > > As the author of that RFC, I can tel

Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

On Tue, 16 Jul 2019 at 16:18, Zeev Suraski wrote: > Given apparently nobody has paid any attention to this email (both in terms > of my support of deprecating hebrevc(), and my request to reconsider > supporting proposals with substantial numbers of 'nay' voters) - I'm > resending it one more

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

On Wed, 3 Jul 2019 at 12:18, Andrew Gromov wrote: > Hello Internals, > > > I just started the vote on > https://wiki.php.net/rfc/deprecate_curly_braces_array_accessand I will > close it in two weeks from now (10.06.2019). > > Thanks in advance to all who paid attention to the vote. > > Best

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

On Fri, 28 Jun 2019 at 23:01, Wes wrote: > Hello PHP, > > I just started the vote on > https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write > and I will close it in one week from now > All votes must be at least 2 weeks long after the "No short votes" RFC passed. Best

Re: [PHP-DEV] Re: Checkout phpdoc

On Tue, 25 Jun 2019 at 23:41, Benjamin Morel wrote: > By the way, is there any work in progress to migrate the PHP manual to Git? > The docs only say: > > The PHP manual is still currently hosted on SVN, although it will be > > migrated to Git in the future. > > >

Re: [PHP-DEV] [RFC] Implement strrstr counterpart to strstr for consistency

On Thu, 20 Jun 2019 at 14:46, Marco Pivetta wrote: > IS it possible to have something with a sensible name? These read like a > diesel engine failing to start up... > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > Oh I totally agree on that but I have no idea

[PHP-DEV] [RFC] Implement strrstr counterpart to strstr for consistency

Hello Internals; I've written an RFC to get feedback about adding a counterpart to strstr to make it more in line with the strpos family of functions which can be found here: https://wiki.php.net/rfc/implement-strrstr-for-consistency I've been mulling over this for quite some time as the PR [1]

<    1   2   3   4   >