> For me (and I am not alone), this feature is NOT a new syntax for closures
Regardless of why you want it, that's exactly what it is though - another way to declare a closure. Even if it has different semantics, the resulting object is still an instance of Closure, right? It should pass type-checks, it should support reflection, and so on - otherwise, that's even more inconsistency, for no practical reason, and it will lead to an endless list of problems which people will solve with even more ugly work-arounds, such as omitting type-hints, etc. > If what you are looking for is a replacement syntax for existing closures, you will have a completely different set of priorities I am not looking for a replacement syntax, but rather a replacement feature. I think the priorities and requirements remain the same, but for consistency, and to keep this feature generally useful, this feature should have parity with current Closures in terms of capabilities - otherwise it will get in the way rather than help. Once people see the nicer, shorter syntax, and start to enjoy the more natural scoping rules, it's going to be very frustrating to have to back-port to the old function-syntax and add use-clauses etc every time the code changes and a single expression doesn't cut it. A single-expression constraint on this feature would be a strange, arbitrary, annoying, unnecessary limitation. We didn't get it right the first time. Let's get it right this time, not just adding another feature as a work-around to certain specific cases. We have closures - no matter how you view it or describe it, regardless of why you want this feature, this is another way to create closures, and it needs to have parity with the existing feature. Unless you're saying these are an entirely new type of object that isn't an instance of Closure, in which case I'd say this whole feature is guaranteed to do considerably more harm than good? On Tue, Jun 20, 2017 at 7:52 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 19 June 2017 21:22:53 BST, Rasmus Schultz <ras...@mindplay.dk> wrote: > >So what's on the table is a syntax-improved but feature-crippled > >variant of > >closures, not an all-round replacement? > > I haven't the time right now to dig out my summary from the mail archives, > but this is one of the fundamental disagreements / misunderstandings that > made discussion difficult the first time: different people want very > different things from this feature, leading to conflicting views on whether > certain things are advantages or disadvantages. > > For me (and I am not alone), this feature is NOT a new syntax for > closures. It is a new TYPE of closure, with new semantics - automatically > capturing variables - for a specific use case. > > Personally, I am strongly opposed to any multi-line version of it, because > I don't want the fundamental scoping rules of the language changed except > for the specific case of simple lambda expressions. > > If what you are looking for is a replacement syntax for existing closures, > you will have a completely different set of priorities. That doesn't make > either of us wrong, but it does mean we're going to find it very hard to > agree on a syntax and feature set. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
