Re: [PHP-DEV] Re: RFC: Nested Classes

On 29 April 2025 19:50:52 BST, "Tim Düsterhus" wrote: >I'm saying that I cannot add a private class Foo\Bar inside of the class Foo >without checking whether a class Bar inside a namespace Foo already exists, >since both would conflict. Even more problematic: I can't add a class Bar >inside

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 21:26, Rob Landers wrote: This was very deliberate after much feedback and careful design. People were quite clear (including yourself, if I recall) that they didn't want a new syntax. Since there is no new syntax, there is no way to tell (from the outside) whether A\B\C refers

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 17:20, Tim Düsterhus wrote: > Hi > > On 4/24/25 17:09, Rob Landers wrote: > > Thank you for your feedback! I think you would then have the problem that > > was pointed out by Levi the other day; where you would then have ambiguity. > > If you could have both private an

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/20/25 15:43, Rob Landers wrote: As it seems that discussion has mostly died down, I'd like to put this towards a vote starting on May 1, 2025. Unfortunately I did not have the time to follow the discussion after mid-March, so this might or might not have been discussed already. I ju

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 17:09, Rob Landers wrote: Thank you for your feedback! I think you would then have the problem that was pointed out by Levi the other day; where you would then have ambiguity. If you could have both private and public names in the same namespace, then you would end up not knowin

Re: [PHP-DEV] Re: RFC: Nested Classes

On Thu, Apr 24, 2025, at 16:31, Tim Düsterhus wrote: > Hi > > On 4/20/25 15:43, Rob Landers wrote: > > As it seems that discussion has mostly died down, I'd like to put this > > towards a vote starting on May 1, 2025. > > Unfortunately I did not have the time to follow the discussion after >

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On Sun, Apr 20, 2025 at 9:30 AM Niels Dossche wrote: > > On 05/04/2025 17:51, Niels Dossche wrote: > > Hi internals > > > > I'm opening the discussion for the RFC "array_first() and array_last()". > > https://wiki.php.net/rfc/array_first_last > > > > Kind regards > > Niels > > > > > Hi > > I'll be

[PHP-DEV] Re: Sentential Entity 6.5 - Mine and Sparx lastest OS based in Ubuntu but an enliving machine (Something to also forward on)

For Recommending to people please read the manuals + guides:~ extract Sentential Entity 6.5 AMD64 Manuals as Tiesaa Binders extract Sentential Entity 6.5 AMD64 Guides as Tiesaa Binders extract Sentential Entity 6.5 ARM64 Manuals as Tiesaa Binders extract Sentential Entity 6.5 ARM64 Guides as Tiesa

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Tue, Apr 22, 2025, at 19:22, Levi Morrison wrote: > On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > > > Hello internals, > > > > I have significantly revamped the RFC (again). Key changes to the RFC: > > > > 1. More (realistic)

Re: [PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Sun, Apr 20, 2025 at 7:46 AM Rob Landers wrote: > > On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are a

Re: [PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 22/04/2025 18:51, Levi Morrison wrote: > I don't think it blocks this RFC in any way, and could be made > frameless after the vote--I just wanted to bring up that I think > they _should_ be frameless if they get accepted (and update > array_key_first/array_key_last to be frameless too). Hi Ind

[PHP-DEV] Re: [RFC] [Discussion] array_first() and array_last()

On 05/04/2025 17:51, Niels Dossche wrote: > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels > Hi I'll be putting this to vote on Tuesday 22nd if no one has complaints. Kind regards

[PHP-DEV] Re: RFC: Nested Classes (was: short and inner classes)

On Mon, Mar 31, 2025, at 21:45, Rob Landers wrote: > Hello internals, > > I have significantly revamped the RFC (again). Key changes to the RFC: > > 1. More (realistic) examples, > 2. Since enums are basically specialized classes, they are allowed to be > nested as well (hat tip to Reddit), > 3.

[PHP-DEV] Re: Declaration-aware attributes

To follow up on this idea. A less problematic solution would be to have a global function or static method similar to func_get_args(), that can only be called from within the constructor of an attribute. A function would be the most natural. But if we are afraid of name clashes with userland funct

Re: [PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer wrote: > > On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer > wrote: >> >> >> Since a lot of the discussion seems to be around static analysis and whether >> there is a real use case for this, I wanted to share another use case I just >> came across:

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer wrote: > > Since a lot of the discussion seems to be around static analysis and > whether there is a real use case for this, I wanted to share another use > case I just came across: in the `thephpleague/commonmark` package, > different renderers are

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

On Mon, Mar 10, 2025 at 12:05 PM Daniel Scherzer < daniel.e.scher...@gmail.com> wrote: > Hi internals, > > I'd like to start discussion on a new RFC about allowing `never` for > parameter types when declaring a method. > > * RFC: https://wiki.php.net/rfc/never-parameters-v2 > * Implementation: htt

[PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Feb 21, 2025 at 12:09 PM Daniel Scherzer < daniel.e.scher...@gmail.com> wrote: > Hi internals, > > I recently found out that constructor property promotion cannot be used > for final properties. I propose that it become allowed. Thoughts? Would > this need an RFC, or is this minor enough t

[PHP-DEV] Re: PHP True Async RFC - Stage 2

Good day, everyone. Just a ping email — I haven’t disappeared, development is ongoing. Since the task has a high level of interdependency, I have to cautiously try different combinations. The second-to-last version, in trying to satisfy all requirements, turned out too complex to be taken serious

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

Hi Am 2025-03-19 15:01, schrieb Volker Dusch: Tim will take care of finalizing the implementation in the coming days. The implementation was merged yesterday and the nightly tests of Symfony / PHPUnit / Composer exposed that the `LOCK_UN` case of `flock()` was not considered when applying th

[PHP-DEV] Re: PHP True Async RFC - Stage 2

Hello everyone, It's a nice Sunday evening, and I'd like to share some updates and thoughts from this week — kind of like a digest :) 1. Big thanks to Rowan Tommins for the syntax suggestions, ideas, and feedback. I decided to try using the `spawn block` syntax, and in practice, it turned out to

Re: [PHP-DEV] Re: RFC: short and inner classes

On 24 March 2025 09:20:03 GMT, "Alexandru Pătrănescu" wrote: >On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield >wrote: > >> >> So, how would nested classes compare to fileprivate, in terms of ability >> to solve the problem space? As I understand it, the goal is: >> >> 1. Classes that can be i

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Mon, Mar 24, 2025 at 11:22 AM Larry Garfield wrote: > > To answer the original question: I'm not against this change, but as it is > a syntax change, I think it does warrant an RFC, even if it's a small/easy > one. That's a good way to flesh out the edge cases like that. > > --Larry Garfield

Re: [PHP-DEV] Re: RFC: short and inner classes

On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield wrote: > > So, how would nested classes compare to fileprivate, in terms of ability > to solve the problem space? As I understand it, the goal is: > > 1. Classes that can be instantiated only by the class that uses them. > 2. But can be returned fro

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Mar 21, 2025, at 2:29 PM, Daniel Scherzer wrote: >>> Yes, that would result in constructor property promotion. I'll need to >>> retarget the original PR for master, but at >>> https://github.com/php/php-src/pull/17861 you can see in >>> `Zend/tests/property_hooks/final_prop_promoted_2.p

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 5:10 AM, Rob Landers wrote: > Hello internals, > > I've made some major updates to the text of the RFC to clarify > behaviors and revisited the implementation (which is still under > development, though I hope to have a draft by the end of this weekend). > Here's a broa

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Mar 21, 2025 at 9:30 PM Daniel Scherzer wrote: > > On Fri, Mar 21, 2025 at 9:45 AM Alexandru Pătrănescu > wrote: > >> >> On Fri, Mar 21, 2025 at 5:20 PM Daniel Scherzer < >> daniel.e.scher...@gmail.com> wrote: >> >>> On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote: >>> Can you

Re: [PHP-DEV] Re: Constructor property promotion for final properties

Hi Am 2025-03-20 21:12, schrieb Daniel Scherzer: I recently found out that constructor property promotion cannot be used for final properties. I propose that it become allowed. Thoughts? Would this need an RFC, or is this minor enough to be acceptable with just a mailing list discussion? Gi

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Mar 21, 2025 at 9:45 AM Alexandru Pătrănescu wrote: > > On Fri, Mar 21, 2025 at 5:20 PM Daniel Scherzer < > daniel.e.scher...@gmail.com> wrote: > >> On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote: >> >>> Can you clarify if the following would result in constructor property >>> promo

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote: > Can you clarify if the following would result in constructor property > promotion or not: > > class Foo { > public function __construct( > final string $bar, > ) { } > } > > Best regards > Tim Düsterhu

Re: [PHP-DEV] Re: Constructor property promotion for final properties

On Fri, Mar 21, 2025 at 5:20 PM Daniel Scherzer wrote: > On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote: > >> Can you clarify if the following would result in constructor property >> promotion or not: >> >> class Foo { >> public function __construct( >> final stri

[PHP-DEV] Re: [VOTE] Add get_error_handler(), get_exception_handler() functions

Hi, The voting has ended. The RFC was accepted unanimously with 28 (Yes) to 0 (No) votes. Thank you for your participation. Kind regards, Arnaud On Wed, Mar 5, 2025 at 10:50 AM Arnaud Le Blanc wrote: > > Hi, > > I just started the vote on the "Add get_error_handler(), > get_exception_handler()

[PHP-DEV] Re: PHP True Async RFC - Stage 2

Good day, everyone. As I write more code examples, I'm starting to get annoyed by the verbosity of the `spawn in $scope` construct—especially in situations where all spawns need to happen within the same context. At the same time, in 80% of cases, it turns out that explicitly defining `$scope` is

Re: [PHP-DEV] Re: PHP True Async RFC - Stage 2

> > await $some limit 5s; > Yes, limit is also a good keyword. And some else examples with "until": **CancellationExp**: - A variable of the `Awaitable` interface ```php $cancellation = new Future(); $result = await $coroutine until $cancellation; ``` - A function that returns an Awai

Re: [PHP-DEV] Re: PHP True Async RFC - Stage 2

```php await $some with 5s; ``` Maybe ```php await $some limit 5s; ``` On Thu, Mar 20, 2025 at 9:33 AM Edmond Dantes wrote: > Hello everyone, > I’d like to ask for your help regarding the syntax. > > **Goal:** I want to get rid of the `BoundedScope` object while still > providing a convenient

[PHP-DEV] Re: PHP True Async RFC - Stage 2

Hello everyone, I’d like to ask for your help regarding the syntax. **Goal:** I want to get rid of the `BoundedScope` object while still providing a convenient built-in tool for controlling wait time. To achieve this, we could extend the `await` expression so that it allows explicitly specifying

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

Hey everyone, The voting has just ended. The #[\NoDiscard] attribute was accepted with 18 (Yes) to 4 (No) votes (82%). The (void) cast was accepted with 18 (Yes) to 2 (No) votes (90%). Neither vote is a subset of the other, some voters only voted for the #[\NoDiscard] attribute itself and some on

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-14 01:22, schrieb Bob Weinand: […] class constants in uppercase […] enum cases are a notable Exception. They also use PascalCase (both internal enums and the PER-CS coding style as published by PHP-FIG). But that's also a good question for the RFC author: Is defining inner cl

Re: [PHP-DEV] Re: PHP True Async RFC

On 10 March 2025 03:55:21 GMT, Larry Garfield wrote: >Support for nested blocks is absolutely mandatory, whatever else we do. If >you cannot nest one async block (scheduler instance, coroutine, whatever it >is) inside another, then basically no code can do anything async except the >top lev

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-13 21:46, schrieb Rob Landers: I will give \\ a try, but it has to be typed quite a bit when referencing inner classes, so keeping it easy to type is a must. I feel like \\ requires a large movement to type, at least on a qwerty non-english keyboard. Maybe people using other keyb

Re: [PHP-DEV] Re: RFC: short and inner classes

On Wed, Mar 12, 2025, at 11:10, Rob Landers wrote: > On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: >> Hello PHP Internals, >> >> I'd like to introduce my RFC for discussion: >> https://wiki.php.net/rfc/short-and-inner-classes >> >> This RFC defines a short class syntax as well as the ability

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote: > Hey Rob, > > On 13.3.2025 21:46:49, Rob Landers wrote: >> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: >>> Hi >>> >>> Am 2025-03-12 11:10, schrieb Rob Landers: >>> > - Accessing inner classes is done via a new token: ":>" instead of

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 14.3.2025 00:26:03, Rob Landers wrote: My biggest issue with `::` is that it gets weird: class Foo {   public class Bar {}   public const Bar = "";   public static function Bar() {} } echo Foo::Bar; // this is the constant new Foo::Bar(); // this is the class Foo::Bar(); // this is

Re: [PHP-DEV] Re: RFC: short and inner classes

Hey Rob, On 13.3.2025 21:46:49, Rob Landers wrote: On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: Hi Am 2025-03-12 11:10, schrieb Rob Landers: > - Accessing inner classes is done via a new token: ":>" instead of > "::". I don't particularly like that. It is “invented syntax” and I don't

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 21:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > > > the proposal is > > > currently quite complex. > > > > Most of this is just describing how classes work already and going in-depth > > on where there may be confusion --

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: > Hi > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffi

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 1:57 PM Rob Landers wrote: > > > the proposal is > > currently quite complex. > > Most of this is just describing how classes work already and going in-depth > on where there may be confusion -- there are no significant changes to how > classes actually work. The

Re: [PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 13, 2025, at 12:41, Ilija Tovilo wrote: > Hi Rob > > On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > > > Am 2025-03-12 11:10, schrieb Rob Landers: > > > - Accessing inner classes is done via a new token: ":>" instead of > > > "::". > > > > I don't particularly like that. It

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Rob On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus wrote: > > Am 2025-03-12 11:10, schrieb Rob Landers: > > - Accessing inner classes is done via a new token: ":>" instead of > > "::". > > I don't particularly like that. It is “invented syntax” and I don't > think that inner classes are suffic

Re: [PHP-DEV] Re: RFC: short and inner classes

Hi Am 2025-03-12 11:10, schrieb Rob Landers: - Accessing inner classes is done via a new token: ":>" instead of "::". I don't particularly like that. It is “invented syntax” and I don't think that inner classes are sufficiently valuable to dedicate an entire operator to them that could serve

[PHP-DEV] Re: RFC: short and inner classes

On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote: > Hello PHP Internals, > > I'd like to introduce my RFC for discussion: > https://wiki.php.net/rfc/short-and-inner-classes > > This RFC defines a short class syntax as well as the ability to nest classes > inside another class. This introduces a

Re: [PHP-DEV] Re: PHP True Async RFC

>function par_map(iterable $it, callable $c) { > $result = []; > async { >foreach ($it as $val) { > $result[] = $c($val); >} > } >return $result; >} If the assumption is that each call can be asynchronous and all elements need to be processed, the only proper tool is a concurrent i

Re: [PHP-DEV] Re: PHP True Async RFC

On Sun, Mar 9, 2025, at 8:17 AM, Rowan Tommins [IMSoP] wrote: > That leaves the question of whether it would ever make sense to nest > those blocks (indirectly, e.g. something() itself contains an async{} > block, or calls something else which does). > > I guess in our analogy, nested blocks cou

Re: [PHP-DEV] Re: PHP True Async RFC

On Sun, Mar 9, 2025, at 14:17, Rowan Tommins [IMSoP] wrote: > On 08/03/2025 20:22, Edmond Dantes wrote: > > > > For coroutines to work, a Scheduler must be started. There can be only > > one Scheduler per OS thread. That means creating a new async task does > > not create a new Scheduler. > > > >

Re: [PHP-DEV] Re: PHP True Async RFC

> Edmond, > > If you want to make async PHP with multiple processes you have to check > variables semaphored to make it work. > > Hello, Iliya. Thank you for your feedback. I'm not sure if I fully understood the entire context. But. At the moment, I have no intention of adding multitasking

Re: [PHP-DEV] Re: PHP True Async RFC

Edmond, The language barrier is bigger (because of me, I cannot properly explain it) so I will keep it simple. Having "await" makes it sync, not async. In hardware we use interrupts but we have to do it grandma style... The main loop checks from variables set on the interrupts which is async. So yo

Re: [PHP-DEV] Re: PHP True Async RFC

> > I think the same thing applies to scheduling coroutines: we want the Scheduler to take over the "null fiber", > Yes, you have quite accurately described a possible implementation. When a programmer loads the initial index.php, its code is already running inside a coroutine. We can call it the

Re: [PHP-DEV] Re: PHP True Async RFC

On 08/03/2025 20:22, Edmond Dantes wrote: For coroutines to work, a Scheduler must be started. There can be only one Scheduler per OS thread. That means creating a new async task does not create a new Scheduler. Apparently, async {} in the examples above is the entry point for the Scheduler

Re: [PHP-DEV] Re: PHP True Async RFC

> > This is incorrect. "Create an async bounded context playpen" (what I called "async" in my example) > and "start a fiber/thread/task" (what I called "spawn") are two *separate* operations, and > must remain so. > > So, you use *async* to denote the context and *spawn* to create a coroutine. Re

Re: [PHP-DEV] Re: PHP True Async RFC

On Sat, Mar 8, 2025, at 1:05 AM, Edmond Dantes wrote: > Hello all. > > A few thoughts aloud about the emerging picture. > > ### Entry point into the asynchronous context > Most likely, it should be implemented as a separate function (I haven't > come up with a good name yet), with a unique name to

[PHP-DEV] Re: PHP True Async RFC

Hello all. A few thoughts aloud about the emerging picture. ### Entry point into the asynchronous context Most likely, it should be implemented as a separate function (I haven't come up with a good name yet), with a unique name to ensure its behavior does not overlap with other operators. It has

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

On Tue, Mar 4, 2025, 23:22 Tim Düsterhus wrote: > > > Or identify that the function has the NoDiscard attribute and based on > that > > do not optimize away the variable? > > First things first: It's not a super important optimization to have, the > assignment to a variable is one of the cheaper

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

Hi On 3/4/25 23:08, Alexandru Pătrănescu wrote: Just asking, as my engine knowledge is a bit limited, Wouldn't it be possible that when OPcache would optimize away the unused variable assigned to a function, it could detect that that function have the NoDiscard attribute and also remove the attr

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

Hi Tim, On Tue, Mar 4, 2025, 22:16 Tim Düsterhus wrote: > Hi Marc > > Should the `(void)` cast not be accepted, we will only special case the > assignment to `$_` to not be elided, even if OPcache knows that the > function will never return an object. The behavior for other variables > will rema

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

Hi Marc On 3/3/25 17:14, Marc B. wrote: In this thread, I only found the information that currently OPcache does not discard such unused assignments. It would be good to know if such optimization could be considered to not end up in a situation that such optimization would be useful but can't be

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

Hi,Am 03.03.2025 15:30 schrieb Volker Dusch :On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote:Volker and I would like to start discussion on our RFC to allow "Markingreturn values as important (#[\NoDiscard])".Please find the following resources for your reference:- RFC: http

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

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

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

Hi Am 2025-02-14 10:10, schrieb Jakob Givoni: I think all the native attributes so far, with the exception of #[\AllowDynamicProperties], only affect the program at compile-time, or by emitting errors. They don't affect the program otherwise by changing behavior, throwing exceptions etc. (As lon

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

On Fri, Feb 14, 2025 at 1:10 PM Aleksander Machniak wrote: > On 14.02.2025 12:57, Derick Rethans wrote: > > None of the current attributes (ReturnTypeWillChange, > > AllowDynamicProperties, SensitiveParameter, Override, and Deprecated) > > change the behaviour of how a program runs. They only add

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

On 14.02.2025 12:57, Derick Rethans wrote: None of the current attributes (ReturnTypeWillChange, AllowDynamicProperties, SensitiveParameter, Override, and Deprecated) change the behaviour of how a program runs. They only add warnings. with the exception of AllowDynamicProperties to be an actual '

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

On Thu, 13 Feb 2025, Tim Düsterhus wrote: > Am 2025-02-13 09:16, schrieb Jakob Givoni: > > > Attributes were added as a structured replacement for docblock props > > and I don't like it when they affect how a program actually runs (as > > long as you're not using reflection). > > Excluding the

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

On Thu, 13 Feb 2025, Larry Garfield wrote: > On Thu, Feb 13, 2025, at 8:16 AM, Tim Düsterhus wrote: > > Hi > > > > Am 2025-02-12 22:31, schrieb Larry Garfield: > >> I'm still undecided on the RFC overall, but one thing that is > >> problematic is the phrasing of the messages. Currently, the mess

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

On Wed, 12 Feb 2025, Volker Dusch wrote: > On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > > > Volker and I would like to start discussion on our RFC to allow "Marking > > return values as important (#[\NoDiscard])". > > > > Please find the following resources for your reference: > > > >

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

On Thu, Feb 13, 2025 at 3:17 PM Tim Düsterhus wrote: > Hi > > Am 2025-02-13 09:16, schrieb Jakob Givoni: > > Attributes were added as a structured replacement for docblock props > > and I > > don't like it when they affect how a program actually runs (as long as > > you're not using reflection).

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

On Thu, Feb 13, 2025, at 8:16 AM, Tim Düsterhus wrote: > Hi > > Am 2025-02-12 22:31, schrieb Larry Garfield: >> I'm still undecided on the RFC overall, but one thing that is >> problematic is the phrasing of the messages. Currently, the messages >> in the attribute are fragments of an English se

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

Hi Am 2025-02-13 09:49, schrieb Eugene Sidelnyk: I'm just wondering how the new attribute that defines behavior (not just additional metadata) will fit into the rest of the system. See my reply to Jakob: There are already several attributes that define behavior. Do you think it's reasonab

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

Hi Am 2025-02-13 09:16, schrieb Jakob Givoni: Attributes were added as a structured replacement for docblock props and I don't like it when they affect how a program actually runs (as long as you're not using reflection). Excluding the `#[\Attribute]` attribute, PHP currently has 5 native at

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

Hi Am 2025-02-12 22:31, schrieb Larry Garfield: I'm still undecided on the RFC overall, but one thing that is problematic is the phrasing of the messages. Currently, the messages in the attribute are fragments of an English sentence, seemingly designed to fit grammatically with a sentence fra

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

Hello, everyone I'm just wondering how the new attribute that defines behavior (not just additional metadata) will fit into the rest of the system. Right now, return type hints are not implemented just as an attribute, but as "native" type declaration. I mean, what we have right now: function f

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

My thoughts overall on this: 0. I'm not against introducing the attribute, only how it's used/enforced etc. (And, incidentally, what it actually MEANS, see if you can spot that from the rest of my comments) 1. Static analysers and IDEs: I agree with everyone who's said that whether or not the

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

On 2025-02-13 00:52, Volker Dusch wrote: b) Naming of the attribute Nobody mentioned this on the list, but before opening a vote we'd like to heard if the attribute name makes sense to you. On this, it could be spelled #[\MustUse], rather than phrase it as a negative.

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

On Wed, Feb 12, 2025, at 5:52 AM, Volker Dusch wrote: > On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: >> Volker and I would like to start discussion on our RFC to allow "Marking >> return values as important (#[\NoDiscard])". >> >> Please find the following resources for your reference: >

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

On Wed, Jan 29, 2025 at 4:12 PM Tim Düsterhus wrote: > Volker and I would like to start discussion on our RFC to allow "Marking > return values as important (#[\NoDiscard])". > > Please find the following resources for your reference: > > - RFC: https://wiki.php.net/rfc/marking_return_value_as_im

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

On Wed, Jan 22, 2025 at 3:35 PM Tim Düsterhus wrote: > - RFC: https://wiki.php.net/rfc/fcc_in_const_expr > - Implementation: https://github.com/php/php-src/pull/17213 With the two weeks discussion time elapsing later today and given the feedback we received, we plan to open the vote tomorrow pe

Re: [PHP-DEV] Re: Discussion: making continue and break into an expression

On Mon, Feb 3, 2025, at 19:44, Rob Landers wrote: > On Sun, Feb 2, 2025, at 14:35, Dmitry Derepko wrote: >> >>> On Jan 25, 2024, at 12:16 PM, Robert Landers >>> wrote: >>> >>> Hello internals, >>> >>> Now that throwing is an expression, it allows for some very concise >>> programming. What are

Re: [PHP-DEV] Re: Discussion: making continue and break into an expression

On Sun, Feb 2, 2025, at 14:35, Dmitry Derepko wrote: > >> On Jan 25, 2024, at 12:16 PM, Robert Landers >> wrote: >> >> Hello internals, >> >> Now that throwing is an expression, it allows for some very concise >> programming. What are your thoughts on making a break/continue into an >> express

Re: [PHP-DEV] Re: Discussion: making continue and break into an expression

Hi Dmitrii On Sun, Feb 2, 2025 at 2:36 PM Dmitry Derepko wrote: > > I had similar idea to make `break`, `continue` and `return` be expressions > instead of statements to simplify almost the same cases as Robert described > above. > > Grammar corrections in the PR. https://github.com/php/php-src

[PHP-DEV] Re: Discussion: making continue and break into an expression

> On Jan 25, 2024, at 12:16 PM, Robert Landers wrote: > > Hello internals, > > Now that throwing is an expression, it allows for some very concise > programming. What are your thoughts on making a break/continue into an > expression as well? Hi! I had similar idea to make `break`, `continue`

[PHP-DEV] Re: [VOTE] Error backtraces v2

On Thu, Dec 19, 2024 at 4:22 PM Eric Norris wrote: > > Hello internals, > > Apologies, I originally responded to the discussion thread instead of > starting a new thread. > > As it has now been two weeks and discussion has quieted down, I've now > opened the "Error backtraces v2" RFC for voting: >

[PHP-DEV] Re: [VOTE] Attributes on Constants

On Sat, Jan 4, 2025 at 4:03 PM Daniel Scherzer wrote: > > the vote will be open for 3 weeks given the holidays, closing on > 2025-01-06 at 00:00:00 UTC. > > Just a reminder that this will close in 24 hours, if you can vote but > haven't yet > > -Daniel > I have closed the RFC, final vote was 26

[PHP-DEV] Re: [VOTE] Attributes on Constants

> the vote will be open for 3 weeks given the holidays, closing on 2025-01-06 at 00:00:00 UTC. Just a reminder that this will close in 24 hours, if you can vote but haven't yet -Daniel

[PHP-DEV] Re: [VOTE] Persistent curl share handle improvement

On Wed, Dec 11, 2024 at 10:18 AM Eric Norris wrote: > > Hello, > > I've opened the vote for "Persistent curl share handle improvement": > > https://wiki.php.net/rfc/curl_share_persistence_improvement > > I've added a week due to the holidays, so it will last for three > weeks, until 2025-01-02 0:0

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

On Thu, Dec 5, 2024 at 3:57 PM Eric Norris wrote: > > Hello yet again internals, > > I'd like to formally propose a continuation of the original error > backtraces RFC (https://wiki.php.net/rfc/error_backtraces): > > https://wiki.php.net/rfc/error_backtraces_v2 > > We recently had a production inc

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

On Mon, Dec 16, 2024 at 11:17 AM Eric Norris wrote: > > Hello, > > We're nearing the two-week mark, so I'm curious if anyone has any > other feedback or points of discussion for this RFC. > > In particular, I'm interested to know if anyone has thoughts on a > suggestion I had in one of the reply t

[PHP-DEV] Re: [RFC] [Discussion] Error backtraces v2

Hello, We're nearing the two-week mark, so I'm curious if anyone has any other feedback or points of discussion for this RFC. In particular, I'm interested to know if anyone has thoughts on a suggestion I had in one of the reply threads - that we could consider something to the effect of allowing

[PHP-DEV] Re: [RFC] [Discussion] Attributes on compile-time constants

On Sat, Nov 30, 2024 at 9:00 AM Daniel Scherzer wrote: > Hi again, > > Based on feedback to my last thread[1] that an RFC would be needed to > allow attributes on constants, I have just filed > https://wiki.php.net/rfc/attributes-on-constants and added it to the > "Under Discussion" section on th

[PHP-DEV] Re: PHP RFC: Records - questions

On Thu, Dec 5, 2024, at 18:12, Volodymyr Volynets wrote: > Hi, > > I have a question in regards to the proposed PHP RFC: Records. For following > snippet: > > record Result(bool $success, array $error, array $data); > $result = &Result(false, [], []); > $result->with(success: true)->*with(error:

Re: [PHP-DEV] Re: Inaccurate documentation on return values from native functions

On Mon, Dec 2, 2024 at 1:31 PM Rowan Tommins [IMSoP] wrote: > > On 01/12/2024 03:41, mickmackusa wrote: > > I can appreciate that. Going forward, is there any benefit to preserving the > behavior of returning integers beyond -1, 0, and 1? > Should these topically related functions receive a new

Re: [PHP-DEV] Re: Inaccurate documentation on return values from native functions

On 01/12/2024 03:41, mickmackusa wrote: [image: image.png] Please avoid images of text; most of the reasons it's a bad idea on Stack Overflow apply here https://meta.stackoverflow.com/q/285551/157957 plus a lot of mailing list archives and e-mail readers will not show HTML formatting at all

Re: [PHP-DEV] Re: Inaccurate documentation on return values from native functions

> > I am not sure that this is purely a problem with the documentation. > > It seems possible to me that someone updated the documentation to > reflect a > > new intention for these functions. > > Will it not be that these functions will be altered in the core to do > what > > the documentation say

  1   2   3   4   5   6   7   8   9   10   >