@ramsey I changed my vote to yes.
What changed my mind was something @Crell said:
"Traits are a surgical tool with a narrow set of uses, and systems that over-use them cause problems."

The same can be said for default methods. Like traits, there are some specific use cases for them, but if you are using them too much, you are doing something wrong.

There is one thing I still disagree with the RFC. Using default methods to avoid a BC break when adding methods to an interface is a terrible idea.

@gmazzap @mauriciofauth @ramsey No, the RFC adds certain functionality, and improves BC in one way, but not in this other way that's more or less the same either way.

It's not perfect, but still a net win.

@gmazzap @mauriciofauth @ramsey From a completely abstract place:

class A extends B, C {}

and

class A implements B, C {}

would be effectively equivalent in power. The difference is squishy feel stuff.

Classes "are supposed to" have impl, interfaces "are supposed to" have type defs. If done via interfaces, no default method becomes the mental default.

Honestly, for me the strongest arg is "via interfaces is more common," so it's easier for ppl coming to the language.

@gmazzap @mauriciofauth @ramsey At some point in this, effectively, interfaces and abstract classes merge into one concept. What particular syntax that uses is subjective.

I couldn't say why the market has gone with interface-based syntax in most cases without a lot more research, but that seems to be what's happened.

@Crell @gmazzap @mauriciofauth @ramsey

I would take a shot at guessing it’s the mental model. Defining an abstract class is about thinking of an object behavior with multiple levels of inheritance and where that object fit in the hierarchy. Defining interfaces is just about an expected contract where multiple levels of hierarchy are barely relevant. I guess there’s nothing really technical about it, just how the idea embedded in people’s minds.

@deleugpn If we stop talking about syntax differences, and focus on concepts, we find out many languages have a construct that is
both abstraction and partial implementation. And guess what, PHP has it as well, it's abstract class. But other languages allow multiple inheritance from that construct, PHP doesn't. Support multiple names after `extend` and PHP becomes inline with other langs.

@Crell @mauriciofauth @ramsey

@deleugpn It's true that many other langs do not have an abstraction-only construct, like PHP interfaces, but if you add implementation to interfaces, you make abstract classes redundant. And because I doubt you'll ever be able to deprecate abstract classes, than I think we should avoid create a duplicate feature in the language. Especially when we can obtain the same thing other language have by allowing multiple inheritance on abstract classes.

@Crell @mauriciofauth @ramsey

@gmazzap @deleugpn @mauriciofauth @ramsey

Java, Kotlin, and C# all have abstract classes, and interface default methods. Only Swift does not.

I agree it seems redundant, but other languages seem to still keep both.

Also, multiple-inheritance via extends would make interfaces redundant just as much. The conclusion I draw is that the line between the two is much more murky than the Java 2 mindset (still prevalent in PHP) would have us believe.