Re: [PHP-DEV] [RFC] anti-coalescing-operator

On Thu, Oct 24, 2019 at 12:46 PM Stephen Reay wrote: > This sounds like an alternative approach (for solving the same basic > problem) to the nullsafe operator discussed a while back, no? https://wiki.php.net/rfc/nullsafe_calls > > At the risk of hijacking, @matthewrask asked me about ?-> a coup

Re: [PHP-DEV] Re: PHP 7.2.24 Released

On Wed, Nov 20, 2019 at 9:28 AM Jan Ehrhardt wrote: > Remi Collet in php.internals (Thu, 24 Oct 2019 12:58:01 +0200): > >The PHP development team announces the immediate availability of PHP > >7.2.24. This is a security release which also contains several minor bug > >fixes. > > Is 7.2.25 stuck s

[PHP-DEV] PHP 7.2.25 Released (Penultimate bugfix release)

https://www.php.net/supported-versions.php Sara Golemon, Remi Collet Manifest: https://gist.github.com/sgolemon/6206424fc265a5be652b0a384816b387 php-7.2.25.tar.gz SHA256 hash: b2cb1bd46454d33b2c65c2fd559f464cd14e57dd47b953adf5caa77fdf0de52b PGP signature: -BEGIN PGP SIGN

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov wrote: > This has been discussed a while ago already, now as a proper proposal: > https://wiki.php.net/rfc/token_as_object > > tl;dr is that it allows you to get token_get_all() output as an array of > PhpToken objects. This reduces memory usage, impro

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

On Fri, Feb 14, 2020 at 7:44 AM Marco Pivetta wrote: > On Fri, Feb 14, 2020 at 2:38 PM Sara Golemon wrote: > >> Thanks for picking it up, and I agree with your response to Larry. As >> nice >> as it would be to lazy iterate, the scanner is just in NO shape to &

Re: [PHP-DEV] Make sorting stable

On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov wrote: > The only issue I ran into is that this change has a negative impact on code > using illegal comparison callbacks like this: > > usort($array, function($a, $b) { > return $a > $b; > }); > > Let's define what "negative impact" means in this

Re: [PHP-DEV] Make sorting stable

On Wed, Mar 4, 2020 at 12:12 PM Nikita Popov wrote: > On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon wrote: > >> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov >> wrote: >> >>> The only issue I ran into is that this change has a negative impact on >>> c

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: > I’m currently working on a patch for this, so this might help with one > aspect of your proposal. > > Here's a quick&dirty for AF_PACKET, looks like OSX/BSD might need AF_LINK though... https://github.com/php/php-src/compare/master...sgolemon:

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

On Mon, Mar 16, 2020 at 12:49 PM Ben Ramsey wrote: > > On Mar 16, 2020, at 12:48, Sara Golemon wrote: > > > > On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: > > I’m currently working on a patch for this, so this might help with one > aspect of your proposal. &

Re: [PHP-DEV] PHP 8.0 Release Manager Selection

On Thu, Mar 19, 2020 at 10:27 AM Derick Rethans wrote: > With the first alpha of 8.0 due in three months, I think it's time to > start the process of finding and electing release managers for the next > release of PHP. > > Name put forward. 7.2 is in security-only, and it'll be EOL shortly afte

Re: [PHP-DEV] [RFC] Constructor Property Promotion

On Thu, Mar 26, 2020 at 8:31 AM Nikita Popov wrote: > I would like to submit the following RFC for your consideration: > https://wiki.php.net/rfc/constructor_promotion > > This is based on one off the suggestions made in > https://externals.io/message/109220, and some existing discussion on the >

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Sun, Mar 29, 2020 at 3:43 PM Benjamin Morel wrote: > This is the syntax I'm using in brick/varexporter > , and supporting it natively in > var_export() makes sense. > > Ditto Danack's question, adding: "Then why not use brick/varexporter?" -Sara

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 9:06 AM Benjamin Morel wrote: > I don't see a reason not to follow with the short array syntax; the only >> expectation of people using var_export(), AFAIK, is to get valid PHP code; >> they don't care about the syntax, > > If "they" don't care about syntax, then why do yo

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan wrote: > @Sara Golemon > > >> Ditto Danack's question, adding: "Then why not use brick/varexporter?" >> >> -Sara >> > > I punt the question back to you and ask why not use PHP? > > Si

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel wrote: > If "they" don't care about syntax, then why do you? > > > Sorry I was unclear. I was reacting to the argument about broken tests in > php-src. > I meant: they don't have *expectations* about the syntax, but they'll most > likely want to be

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 12:32 PM Sherif Ramadan wrote: > Now, will you answer my question? >> > > Simple. > Wrong. It's complex as this thread proves. Opinions are not in alignment making it non-simple. > Because an implement in php-src is more available, > Wrong. It's got availability FOR THOS

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler wrote: > Just out of curiosity, is there any reason we couldn't add an optional > parameter called "$short_array" or whatever that defaults to false? Then > there shouldn't be any backwards compatibility issues. > > None at all, though I'd make it an

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

On Tue, Mar 31, 2020 at 6:49 AM Jakob Givoni wrote: > I've moved the RFC to the voting phase: > https://wiki.php.net/rfc/compact-object-property-assignment > > On the third vote (which syntax would be better), I didn't vote because my answer is "None of the above". They're all kind of awful. I'm

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

On Mon, Apr 6, 2020 at 2:36 PM wrote: > I have closed the voting. With 38 in favor and 28 against the RFC is > DECLINED (didn’t reach the needed 2/3 majority for a new feature). > > Please don't be discouraged. I did vote against, but I was on the fence (My vote was 'Yes' for a period). Review

[PHP-DEV] PHP 7.2.30 Released!

w.php.net/downloads> Windows downloads:<http://windows.php.net/download> Changelog:<http://www.php.net/ChangeLog-7.php#7.2.30> Migration guide: <http://php.net/manual/migration72.php> Many thanks to all the contributors and supporters! Sara Golemon

Re: [PHP-DEV] [RFC] Mixed type

On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield wrote: > On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > > Here is an RFC for adding a 'mixed' type to the language: > > https://wiki.php.net/rfc/mixed_type_v2 > > > > I am not against this, but now that we have Union types what places are > t

Re: [PHP-DEV] [RFC] Function pipe operator

On Mon, Apr 20, 2020 at 9:39 PM Ben Ramsey wrote: > > On Apr 20, 2020, at 20:38, Larry Garfield > wrote: > > > > I've been commenting on other RFCs enough lately that I should probably > put myself through the wringer, too. I therefore offer this RFC to add a > function pipe operator, as seen i

[PHP-DEV] [8.0] 3-Month Reminder; Feature Freeze is July 28th

Per the current schedule ( https://wiki.php.net/todo/php80 ), PHP 8.0 is set for feature freeze and branching on July 28th which is 3 calendar months from today (13 weeks). I would like to encourage everyone currently working on a proposal to please plan on getting your RFCs into voting no later t

Re: [PHP-DEV] Moving json extension to core?

On Wed, Apr 29, 2020 at 8:11 AM Nikita Popov wrote: > > Doing this would also make some extensions more convenient to use (e.g. > > memcached with the json serializer, using json encoding for uses such as > > error messages in miscellaneous extensions, etc.) > > > > Another advantage would be tha

Re: [PHP-DEV] Moving json extension to core?

On Wed, Apr 29, 2020 at 5:36 PM Benjamin Morel wrote: > I want my classes to implement JsonSerializable, but this means requiring >> ext-json and bumping the library version. >> > > At the risk of derailing... You can have your class implement the interface unconditionally, then have a polyfill d

Re: [PHP-DEV] [RESULT] Re: [PHP-DEV] [VOTE] Round two, PHP 8.0 RM

On Tue, May 5, 2020 at 12:19 PM Derick Rethans wrote: > the vote for the second release manager has been concluded. At a nail > biting 18 vs 19, Gabriel Caruso is chosen! Congrats. > > Congratulations, Gabriel! I assume you're already familiar with https://github.com/php/php-src/blob/master/docs

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

On Tue, May 12, 2020 at 3:26 AM Nikita Popov wrote: > // WeakMap::getIterator(): Iterator > ZEND_METHOD(WeakMap, getIterator) > { > if (zend_parse_parameters_none() == FAILURE) { > return; > } > zend_create_internal_iterator_zval(return_value, ZEND_THIS); > } > Given that the b

Re: [PHP-DEV] Refactoring run-tests.php

On Fri, Jun 5, 2020 at 10:42 AM Max Semenik wrote: > I was thinking about making some improvements to our venerable test runner, > however I wasn't feeling confident about improving the present code base. > Instead, I decided to attempt to refactor it. > > This is a perennial topic and I don't wa

[PHP-DEV] 8.0 release dates

previously Dec 3rd, now Nov 26th). Obviously, this schedule is still subject to change if we find problems during the pre-release which warrant additional time. You may find the revised schedule at https://wiki.php.net/todo/php80 -Sara Golemon

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

On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch wrote: > OMG the trolling continues even today with this nonsense. Disappointing. > Oh yes. And histrionics will certainly deescalate that issue. > "...yes, it is broken, people have to Google or ask around for a very > unclear error message when f

Re: [PHP-DEV] New functions `hash_serialize` and `hash_unserialize`?

On Thu, Jun 11, 2020 at 11:59 AM Eddie Kohler wrote: > Thanks for this suggestion. I've updated the implementation to make > HashContext implement Serializable. > > I'd still be grateful for more feedback, or perhaps I should just create > an RFC? > > Be careful what you ask for. :) Overall +1 o

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

On Mon, Jun 15, 2020 at 4:41 PM Deleu wrote: > As white men, we're being dismissive, insensitive and strongly suggesting > we don't want change. While people may not feel offended by any of these > terms being discussed, this thread alone already serves as reason for > people to feel like there's

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

On Wed, Jun 17, 2020 at 7:23 PM Ben Ramsey wrote: > I don’t understand this question: > > > Are you okay with re-voting on the attribute syntax for PHP 8.0? > > I recommended this as a front-line question so as to remove any hint of impropriety about the vote. For example, where the first round

[PHP-DEV] PHP 8.0.0alpha1 is ready for testing

, Sara Golemon & Gabriel Caruso php-8.0.0alpha1.tar.gz SHA256 hash: dbc1df78f4b4bf758d796c0265b05500ab5e8d501543c5d7f42aeb67c9bbaa13 PGP signature: -BEGIN PGP SIGNATURE- iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLMQHHBvbGxp

[PHP-DEV] 8.0 Feature Freeze in 4 weeks

Per the timetable at https://wiki.php.net/todo/php80 , the PHP-8.0 branch will be cut in FOUR WEEKS on Aug 4th just prior to the release of php-8.0.0beta1 on Aug 6th. Please note that August 4th marks FEATURE FREEZE for 8.0. All RFCs currently in discussion targeting 8.0 should plan to begin votin

[PHP-DEV] PHP 7.2.32 Released

:http://www.php.net/ChangeLog-7.php#7.2.32 Signatures and Checksums: https://gist.github.com/sgolemon/030a3c04cdc8e073bdfb96a3f70f8701 Many thanks to all contributors and supporters! Stay typesafe and wear a netmask! Sara Golemon, Remi Collet

Re: [PHP-DEV] Microsoft Support of PHP on Windows

ha2 builds were produced already. I won't say I'm not bummed, of course. Nevertheless, y'all gotta do what you gotta do. I'm sure we can work out an alternative by the end of the year. All the best, -Sara Golemon (PHP 8.0 Release Manager)

Re: [PHP-DEV] 8.0 Feature Freeze in 4 weeks

On Tue, Jul 21, 2020 at 9:29 AM Nikita Popov wrote: > Just so people aren't surprised, I plan to start landing implementations > for RFCs that are likely to be accepted in advance of the actual vote > closure, as we have many RFC votes ending close to feature freeze. Of > course, if something end

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

On Wed, Jul 22, 2020 at 7:00 AM Derick Rethans wrote: > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > Yes. Because we voted on it. Twice. > - It has the distinct possibility to cause further parsing issues, akin > to what ended up ha

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

On Wed, Jul 22, 2020 at 4:29 PM Sara Golemon wrote: > Citation Needed. > > The '@' token and the T_DOUBLE_AT token come from the lexer as distinct > values, where is the conflict? > > I'm not doubting that there is one, you're quite clever, but at the momen

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

On Thu, Jul 23, 2020 at 1:26 AM Mark Randall wrote: > On 23/07/2020 02:00, Sara Golemon wrote: > > Regards the vote; I don't believe that @@ has been proven unworkable, > > however if I'm wrong about that, then the second choice selection from > the > > last vo

Re: [PHP-DEV] Ternary associativity

On Thu, Jul 23, 2020 at 7:26 AM Nikita Popov wrote: > PHP currently has an incorrect right-associative ternary operator. In > https://wiki.php.net/rfc/ternary_associativity the use of nested ternaries > was deprecated, and was supposed to become an error in PHP 8.0. > > Concurrently with that pro

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

On Thu, Jul 23, 2020 at 10:19 AM Sara Golemon wrote: > If that's the case, then the solution still seems obvious: Defer > attributes to 8.1. > > After some discussion off list, including Nikita (who is probably closer to this "problem" than any of the rest of us), I th

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

On Fri, Jul 24, 2020 at 10:10 AM Nikita Popov wrote: > > > You added PHP 8.0 as a proposed version, but that will not be possible > > > anymore 2 weeks of discussion + 2 weeks of voting are not possible to fit > > > in before the feature freeze, which is in 11 days. > > > > While you are technical

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

On Mon, Jul 27, 2020 at 5:25 PM Rowan Tommins wrote: > A couple of months ago I revived my suggestion to make stream wrappers > advertise HTTP/1.1 by default (full message below), and then Real Life > intervened and I didn't raise the PR. > > The implementation (which is a one-character change) i

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins wrote: > The risk of advertising 1.0 by default is that some software will have been > programmed to outright refuse that protocol version. I don't know of any > recent examples, but this bug report from 2007 was for a SOAP endpoint that > returned 50

[PHP-DEV] 8.0 Feature Freeze

FF officially hits on Tuesday, so here's the status of the repo: IF YOUR EMAIL ADDRESS IS INCLUDED IN THE TO: FIELD, THEN YOU HAVE HOMEWORK ATTACHED. RFCs still in voting phase: * StackFrame class: This seems poised to fail, so no action needed. * Phar Metadata unserialization: This is poised to o

[PHP-DEV] Resource to Object conversion

I just learned about https://github.com/php/php-tasks/issues/6 Is it the case that we've agreed as a whole to simply make these conversions (as quiet under-the-hood, should only break is_resource() type of changes) without need for individual RFCs? Or is a perfunctory RFC and vote called for on ea

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote: > It provides a small BC break where code written as @[$foo, $bar] = baz(); > or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can > be easily > fixed by writing it with a space between @ and [. > > If those are the pot

Re: [PHP-DEV] 8.0 Feature Freeze happening today

On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote: > Sorry, I didn't catch that this message said feature freeze *and branch*. > > Please do not create a separate PHP-8.0 branch yet. A separate branch is > only needed if anyone wants to start landing changes targeting PHP 8.1 > already -- as far

Re: [PHP-DEV] 8.0 Feature Freeze happening today

On Tue, Aug 4, 2020 at 1:41 PM Christoph M. Becker wrote: > On 04.08.2020 at 20:22, Sara Golemon wrote: > > On Tue, Aug 4, 2020 at 12:01 PM Nikita Popov wrote: > > > >> Sorry, I didn't catch that this message said feature freeze *and branch*. > >> > &

Re: [PHP-DEV] Putting the match expression in constant expressions in PHP 8.0 or 8.1

On Fri, Aug 7, 2020 at 7:22 PM tyson andre wrote: > The match expression can be thought of as a much more concise/readable > equivalent to chained ternary operators. > I'm proposing allowing matches in constant expressions when all parts of > the match are constant expressions. > > That seems pre

[PHP-DEV] Null-safe property access in interpolated strings

Do we expect this to work? $foo = new stdClass; $foo->bar = "Hello"; echo "$foo?->bar world\n"; Because at the moment it doesn't: https://3v4l.org/nLv3l -Sara

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

On Sat, Aug 8, 2020 at 3:42 PM Ilija Tovilo wrote: > > > I just noticed that while we support "$a->b", we do not support > "$a?->b" (the quotes are relevant -- I'm talking about interpolated strings > here). That is, in the latter case the "?->b" is just treated like a string > part, not like a p

Re: [PHP-DEV] ZEND_ENGINE_4 define?

On Mon, Aug 10, 2020 at 2:37 AM Nikita Popov wrote: > On Mon, Aug 10, 2020 at 7:57 AM Philip Hofstetter < > phofstet...@sensational.ch> wrote: > > In many cases, I've been using the ZEND_ENGINE_3 define to handle the > > PHP 5/7 difference. > > > > Now, the Zend Engine version seems to have been

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote: > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > > Just chiming in to say all, y'all voting for @[...] are making a terrible choice, and are you sure you're okay with it? We have options with varying degrees of backward com

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, Aug 11, 2020 at 10:07 AM guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > I'd like to explain my rationale. Most of the time I end up using > "#[todo] Whatever" while documenting my code... my intentions are "# > [todo] ...", but you know... missing that space char doesn't b

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, Aug 11, 2020 at 11:25 AM Andreas Leathley wrote: > This would be a feature if libraries start parsing PHP token by token > and start supporting the #[] syntax for the 7.x versions of PHP - then > early adoption would be possible and it would be a real feature. But it > seems unclear if th

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, Aug 11, 2020 at 11:38 AM Sara Golemon wrote: > PHP 8+ performance on theses would certainly be between though, and that's > an extra carrot to push users to upgrade. If annotations can't be written > until after users upgrade, then that carrot vanishes. > *PHP 8

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown wrote: > It has just come to my attention that this RFC was rushed to vote > after less than the minimum two week period required after it was > brought up on list. Furthermore, discussion was still very active at > that time - I certainly didn't hav

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown wrote: > I was very surprised that it went to vote less than six days after > the discussion period started, right after the weekend no less, > before I had a chance to submit my patch to include the @: syntax. > > Yes. Derick fucked up the *letter*

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Sun, Aug 16, 2020 at 4:29 AM Benjamin Eberlei wrote: > Following the valid criticisms of us starting the vote too early, we have > closed the vote for this RFC for now. > > We look to restart the vote middle next week, so that we can close this > before the Beta 3 release on September 3rd. > >

[PHP-DEV] PHP 8.0.0 Beta 2 Ready for Testing

bug system: https://bugs.php.net 8.0.0beta3 should be expected in 2 weeks, i.e. on Sep 3, 2020. Hash values and PGP signatures can be found below or at https://gist.github.com/sgolemon/1694e5313d246eaf203318d516d53fba Thank you, and happy testing! Regards, Sara Golemon & Gabriel Caruso

Re: [PHP-DEV] Support PAM in PHP8

On Fri, Aug 21, 2020 at 10:43 AM Benjamin Eberlei wrote: > The code needs to be maintained by someone to be up to date, putting it > into php-src will not magically solve that issue. > > THIS x1000. The first test for getting something into core is that it is stable and used. If the original au

Re: [PHP-DEV] array_reject() as counterpart of array_filter()

On Mon, Aug 31, 2020 at 9:41 AM David Rodrigues wrote: > > I agree with Larry that userland implementation is trivial enough that it > > doesn't really need to be implemented in core. It's just syntactic sugar > > that's probably more trouble than it's worth. That being said, I'm by > far > > an

Re: [PHP-DEV] array_reject() as counterpart of array_filter()

On Mon, Aug 31, 2020 at 10:35 AM David Rodrigues wrote: >> It should be possible for the engine (at some layer) to look at that closure >> and see that it's just negating some proxied call and elide setting up the >> intermediate frame. Microoptimizations SHOULD be the engine's job, not userspace

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

On Wed, Sep 2, 2020 at 9:31 AM Thomas Bley wrote: > Hello, > > I'd also like to propose to use null: > > [null, null, $username] = getUserData(); > > foreach ($source as $key => null) {} > > These both look like great, expressive syntaxes. No new keywords, no major change to existing idioms, jus

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

On Wed, Sep 2, 2020 at 2:11 PM David Rodrigues wrote: > I understand... seems that `$this` is very confusing inside `__clone()`: > when writing, it writes to the clone, when reading it reads from original. > > That's not an accurate description of what happens today. $newObj = clone $oldObj; //

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer wrote: > > I currently use foreach (array_keys($array) as $key) { ... } > > to avoid complains from code analysers on unused var, is it slower? > > one argument brought forward initially (sorry, can't find the email > right now) is the resource mana

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

On Mon, Aug 31, 2020 at 6:56 PM tyson andre wrote: > I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable > > I've probably reached this thread too late, but I'm going to throw out my old chestnut that these things don't belong in the engine. They belong in userspace. 1. Instant

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues wrote: > Now I rethinked about what I said. Really, maybe clone is not the best > option. So maybe we can just use a method that will clone and will have > access to both informations. But I don't know if it solves the original > message. > > public

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues wrote: > Do you think that it could be proxied? I mean, optimize foreach > (array_keys()...) syntax to not call array_keys() in fact, but a optimized > version of foreach to handle key only. I don't know it opcache could do > that, and if it already

Re: [PHP-DEV] Pass source object to clone like __clone($origThis)

On Thu, Sep 3, 2020 at 11:03 AM David Rodrigues wrote: > It was just an example to avoid modify how clone works, using existing > features. :) > Right, but the question remains "Why would we want the original object during a clone operation?". No legitimate example of that has been provided y

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

On Thu, Sep 3, 2020 at 8:23 PM Levi Morrison wrote: > > 3. Better visibility from the JIT (not having to cross > userspace/internals > > border is good) > > This is a good point _in theory_, but to me this is just indicative > that we need to be able to bundle built-in functions for php-src. Now

[PHP-DEV] PHP 8.0 branch cut

Next Tuesday, Sep 15th, has been marked on my calendar as the branch date for PHP-8.0 which would open master up for 8.1 targeted work. This would mean that bug fixes would need to include PHP-8.0 in their merge chain (meaning more work to merge 8.0 targeted fixes). Please let Gabriel and I know

Re: [PHP-DEV] PHP 8.0 branch cut

On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov wrote: > On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon wrote: > >> Next Tuesday, Sep 15th, has been marked on my calendar as the branch date >> for PHP-8.0 which would open master up for 8.1 targeted work. >> >> This w

[PHP-DEV] PHP 8.0.0 Beta 4 available for testing

b.com/sgolemon/ddef47870381cae12120d41f59374847 Thank you, and happy testing! Regards, Sara Golemon & Gabriel Caruso php-8.0.0beta4.tar.gz SHA256 hash: dacbb783e9481bb16f879e9a3800e409e45dcec1f1a05974df3f99da7593d09c PGP signature: -BEGIN PGP

Re: [PHP-DEV] Attributes and strict types

On Tue, Sep 22, 2020 at 7:59 AM Nikita Popov wrote: > I would like to clarify how attributes are supposed to interact with > strict_types. Consider the following code, split up into three files to > make it clear that each one could have their own strict_types mode: > > MyAttribute.php > #[Attri

Re: [PHP-DEV] Attributes on property groups

On Tue, Sep 22, 2020 at 7:51 AM Nikita Popov wrote: > Currently, placing an attribute on property (or constant) groups is not > allowed: > > This is a case that was not explicitly mentioned in the RFC and we decided > to be conversative when landing the initial implementation. > > Conservative is

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

On Tue, Sep 29, 2020 at 5:00 PM Gabriel Caruso wrote: > I'm gonna borrow Nikita's idea, and tag RC1 today without cutting the PHP-8.0 branch. > Late to the conversation, but I stand by Gabriel's call to proceed with release names as-is, but defer branching till RC2. To be clear, we're calling the

Re: [PHP-DEV] Attributes and constructor property promotion

On Mon, Sep 28, 2020 at 5:36 AM Nikita Popov wrote: > When the constructor property promotion landed, the question of how it > interacts with attributes on promoted properties did not get fully > resolved. See https://wiki.php.net/rfc/constructor_promotion#attributes > for > what the issue is. >

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

On Thu, Oct 8, 2020 at 2:49 AM Nikita Popov wrote: > At this point we have a number of PHP-8.1 only changes pending, so I think > it would make sense to go ahead with the branch cut now. Any concerns with > doing that today/tomorrow? (I don't think we need to synchronize this with > the next rele

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

On Mon, Oct 12, 2020 at 7:55 AM Christoph M. Becker wrote: > > On 12.10.2020 at 13:49, Hans Henrik Bergan wrote: > > > something like > > > > $result = (new HashContext("SHA1"))->update($str1)->update($str2)->final(); > > > > (userland sample imp: https://3v4l.org/lXd3u ) > > > > I tried asking on

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

On Tue, Oct 13, 2020 at 11:42 AM Christoph M. Becker wrote: > > > Happy to co-author an RFC with you if you'd like to get involved > directly, > > or I can just pick up the ball and run with it if you'd rather make the > > feature request then step back. > > Please go with this, if you like. Not

Re: [PHP-DEV] PHP 8 release announcement page on php.net

On Wed, Oct 14, 2020 at 6:18 AM Dik Takken wrote: > > However, then we should also make sure that the example > code actually works, and on which PHP versions. As soon as examples can > be run right from the documentation pages, the examples will be run far > more frequently than they are now, sim

[PHP-DEV] PHP 8.0.0 RC2 Ready for Testing

lemon/c7a4e75c3d304d781de4289b31c487f9 Thank you, and happy testing! Regards, Sara Golemon & Gabriel Caruso php-8.0.0RC2.tar.gz SHA256 hash: 0cebc11c61c0f153bd866eab76c424404b3ccc779417cdfde1061e550c3e364c PGP signature: -BEGIN PGP SIGNATURE- iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl+GI44QHHB

Re: [PHP-DEV] PHP 8 release announcement page on php.net

On Thu, Oct 15, 2020 at 9:25 AM Benjamin Eberlei wrote: > > 1. October: RMs and/or php-web maintainers should give their go on the idea > (someone else?), so that more detailed creative time investment is not > going to waste. FTR they came to Gabriel and I *first*. Sounded like a neat idea to b

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

On Tue, Oct 13, 2020 at 12:04 PM Sara Golemon wrote: > On Tue, Oct 13, 2020 at 11:42 AM Christoph M. Becker > wrote: > >> >> > Happy to co-author an RFC with you if you'd like to get involved >> directly, >> > or I can just pick up the ball and run w

[PHP-DEV] [RFC] HashContext OOP api discussion period opened

https://wiki.php.net/rfc/hash.context.oop

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

On Wed, Oct 21, 2020 at 9:59 AM G. P. B. wrote: > 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

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

On Mon, Oct 5, 2020 at 5:09 AM Lynn wrote: > How should php deal with the scenario where you want to `use` everything > and have one variable by reference? > > ``` > function () use (*, &$butNotThisOne) {}; > ``` I would take a page out of C++'s book here. In C++ a closure is (some of these bits

Re: [PHP-DEV] Rename PhpToken::getAll()?

On Sat, Nov 7, 2020 at 3:09 AM Nikita Popov wrote: > The PhpToken::getAll() API introduced in PHP 8.0 is of course inspired by > the existing token_get_all() function. But arguably, the name is not that > great. > > The reporter suggests to rename it into PhpToken::tokenize() instead, which > see

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

On Sat, Nov 7, 2020 at 9:33 AM Olle Härstedt wrote: > 2020-11-07 15:12 GMT, Eugene Sidelnyk : > > function foo(A & B & E $object) { > > // some work > > var_dump($object); > > } > > > > You mean intersections? Psalm supports this notation. > > IIRC we discussed intersection data types when un

Re: [PHP-DEV] php-src Git hash abbreviation collisions

On Sat, Nov 7, 2020 at 5:14 AM Christoph M. Becker wrote: > I've just noticed a pull request[1] which suggests to no longer > abbreviate the php-src Git hashes to 7 digits only, because there are > already collisions. Using 10 digits as suggested seems reasonable to > me, but I wanted to check i

Re: [PHP-DEV] Alias for `int|float`

On Sun, Nov 8, 2020 at 11:09 AM Eugene Sidelnyk wrote: > What do you think about creating shorthand `number` for `int|float`? > Others have pointed at a few reasons why not, but I'd like to add that if we allow type aliasing, then projects can choose to define this or not. I'd rather see the pow

Re: [PHP-DEV] Why there is no StreamWrapper interface ?

On Thu, Nov 12, 2020 at 7:00 AM Pierre wrote: > This might be a stupid question, or it may have already been answered > tons of times, but is there any valid reason for not having a > StreamWrapper interface as documented there: > https://www.php.net/manual/en/class.streamwrapper.php > > Or if so

[PHP-DEV] Preparing for PHP 8.0.0 GA

I've just cut the release branch for PHP-8.0.0 final which will be released in one week on 26 Nov. Minor bug fixes can continue to be merged via the PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what 8.0.0RC5 contained unless serious issues are encountered. If you feel you ha

Re: [PHP-DEV] [RFC] Draft - Closure self reference

On Wed, Nov 11, 2020 at 12:37 PM David Rodrigues wrote: > My suggestion is to reuse the keyword `as` to set a variable that will > represent its own closure. It is more flexible once that we could choose > any name and reuse in nested closures. It is pretty similar to how SQL > works too. > > fun

Re: [PHP-DEV] [RFC] Draft - Closure self reference

On Fri, Nov 20, 2020 at 11:40 AM Larry Garfield wrote: > > (5) function $lambda(... $args): returnType use ($captures...) {} > > > > To be honest, as I typed what came to mind, I ended up preferring this > last > > option. > > I kind of like that option, too. Agreed that this has some attractiv

Re: [PHP-DEV] [RFC] Draft - Closure self reference

On Fri, Nov 20, 2020 at 12:58 PM Guilliam Xavier wrote: > > I don't know if that would be a problem, because today we can have it > > "function(): Type use($x)", so "Type use($x)"? > > > > No we can't, try it (Parse error). The correct order is > "function() use($x): Type". > > Ugh. That's ugly.

<    3   4   5   6   7   8   9   10   11   12   >