Serhii Cho

I honestly don't really care about that small sugar, but I lean more towards yes than no, so ship it

makes for cleaner code by removing those useless parentheses

Cleaner code

this allows for cleaner code. less verbose.

Looks like a good idea. first, I thought it will be too complicated for PHP to have this kind of syntax, but I've changed my mind, I think it will be amazing to have it in the language

Since I'm working also with Kotlin I desperatly crave for a feature like this. At least if it is as powerful as in Kotlin where I could e.g. change the setter to be protected or private while the getter can be public

Love it. like in swift. If property observers could be added this would be awesome!

Provides a nice code structure keeping together: declaration, getter and guarded setter

I'm against a multi-inheritance in OOP. I don't think this RFC is necessary for the language. The current OOP system in PHP is already well developed.

I don't usually like syntactic sugar added to the PHP, but this RFC is useful. I totally see use cases for this in my projects because I use short closures all the time.

Such an awful RFC and people are voting for it 😱, weird. I agree with Rasmus Lerdorf, Nikita Popov and Sebastian Bergmann, this PR should NOT go into the language.

I think we should focus more on improving the performance and fixing things that people don't like in PHP rather than implementing new features.

We already have a solid language that does so many things for us, everything else is provided by frameworks. I understand why people want to see features like this one, but I would prefer to focus on the performance and cleaning up the codebase of PHP source code.

this syntax is unclear, and functions who gets multiple arguments will not be properly supported.

I see no immediate benefit of the proposed solution over the userland implementations. The RFC mentions a shopping cart example, but I don't think that's cleaner than using league/pipeline or Laravel's pipeline.

It's a bit messy for the simpler examples as well.

It's almost as messy as putting all the functions into each other.

Makes code more clean because it is shorter and the use keyword is not needed anymore.

Since we have already autocaptures for one liners there should be also option for multiple liners.

Interfaces are contracts. No implementations should be allowed.

The use statements are usually what is keeping me from using the short closures, so having this resolved would make life a lot easier in those cases and the code cleaner

I don't think we need to add business logic to interfaces. Interfaces are contracts, that's the whole beauty of interfaces (that, and the fact that they encourage composition over inheritance, which imo leads to code that is easier to maintain). Having default methods would pollute that premise.

We can already do this with abstract classes. I believe Interfaces should be contracts that leave the implementations up to the implementing classes.