Arziel

Just why not :)) No one was forced to use them, but when it's introduce it has many useful applications.

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

As with all other RFC with 'adding' behaviour, if you don't like it, just don't use it and left it for others :))

Technically writing a trait isn't a showstopper, but it adds cognitive load because the developer now must know/remember using this Interface requires adding this Trait. PHP should focus more on development experience!

I personally don't need it but I guess it could be useful to people.

It will solve having to create traits to add a default implementation when creating interfaces and keeping it nicely together improving the DX

Multi-inheritance seems to be the hot topic that prevented this RFC from being approved even though it was not the RFC target. Multi-inheritance is an afterthought that may or may not be abused with this change. What we want would actually be just the convenience of doing what Traits already allow while reducing potential BC break impact coming from interface changes. There are interfaces originated from the interface segregation mindset that often has only 1 implementation and could very well take advantage of default implementation for a simpler system design.

We spend a lot more time reading code than writing it. The elegance of short closure combined with the convenience of variable scope usage has already shown to be a game changer on Typescript and there doesn’t seem to be any technical issue with having it on PHP.

At least once a week, I throw away an array_map because it ended up looking too bloated and go with a classic foreach instead. Short Closures 2.0 without the use(...) block would've solved this problem, just 2 votes...

I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.