On Sun, Jun 12, 2022 at 2:29 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 11/06/2022 23:01, Deleu wrote: > > The RFC does mention that the existing Anonymous Function Syntax > > remains untouched and will not be deprecated. Whether the new syntax > > is better for nearly all closures will be a personal choice. > > > I honestly don't think this is how it will be perceived. If this syntax > is approved, people will see "fn" as the "new, better way" and > "function" as the "old, annoying way". > And to me that's not an argument to deny what people want. > To put it a different way: imagine we had no closure support at all, and > decided that we needed two flavours, one with explicit capture and one > with implicit capture. Would we choose "function" and "fn" as keywords? > I often don't indulge such hypotheticals because we will never truly be able to make progress based on such an assumption. A breaking change that changes how closure works is just not gonna happen. Given the current state in the world we're in, what can we do to have a better DX on anonymous functions? > > > The previous discussions talked about use(*) or use(...) and most > > people I know that would love this RFC to pass would also dislike that > > alternative. It does not have the greatest asset for short closure: > > aesthetics. [...] All I can say is that use(*) is not a replacement > > for the RFC. > > > I think you're trying to have it both ways here: if you really believed > that the two syntaxes were going to live side by side, there would be no > reason for "aesthetics" to be any more important for one than the other. > > Some people are of the opinion that automatic capture should always have > been the default, and the current syntax is a mistake. I'm fine with > that opinion, but I want people to be honest about it rather than > pretending they're just adding a new option for a narrow use case. > > Honestly I don't think it was a mistake. It was designed more than a decade ago and there was no way of predicting the future. I've seen code written 20~10 years ago and I've seen code written 5~0 years ago. I think the best decision was taken at the time it was taken and the world of development has changed enough for us to make different decisions now. It's not that I'm trying to have it both ways, I'm just not assuming my view is the right one. I do believe that if such an RFC is approved, I will almost never reach for `function () use ()` anymore because I will prefer the short syntax. If I need a new scope I will reach for an invocable class. But that doesn't mean other teams/projects/people are forced to agree or follow the same practices as me or my team. > > > Any attempt to make it explicit defeats the purpose of the RFC. > > > That depends what you think the purpose of the RFC is, which is what I > want people to be honest about. > > If the purpose is to replace long lists of captured variables, an > explicit "capture all" syntax like "use(*)" achieves that purpose > perfectly fine. > > If someone decides to implement `function () use (*)` on a separate RFC, I would abstain from that because it's not something I'm interested in using and it doesn't address the aesthetic issue we have today. I just don't like it being considered an alternative to the current RFC because it's not. The purpose is to replace long lists of captured variables while addressing the aesthetic issue caused by `use ()`, which is the only place in the language we use this construct. It seems to me that you agree that there is a chance the proposed syntax is going to be perceived as better and people will not want to use the old syntax anymore and that makes you not want to accept the RFC. Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Marco Aurélio Deleu
