>> I want to pitch in, agreeing with Larry's message here. >> >> - There are multiple real life use cases where the combo trait/interface >> could be replaced by interface default methods >> - Several modern language apply the technique in one form or another, so >> it's already proven to be valuable >> - There are a multitude of userland devs who'd benefit from this feature >> - The only argument I've heard against this RFC is "it goes against my >> definition of what an interface should be". I was also thought that same >> definition, and I also had to unlearn it. Just like I had to unlearn the >> "only one return per method rule" we were taught in college >> >> Brent >>
> If it's a time constraint, it would be good to hear more from folks that > voted no so that it can light up hope. > If it's just because voters don't want to let us have this then it's really > just frustrating. Hey internals, I know that I'm not that active around here but I wanted to give my 2 cents I totally agree with this. We already have other languages that use this in one way or another and it's a valuable feature for all these languages. This is something that would save a lot of "boilerplate" code and workarounds using Interfaces+Traits in a lot of places. Also, this would be an opt-in thing, if you don't want to use default methods in the interfaces and keep them just acting as "plain interfaces" it won't change anything for you. I don't see why this is having such a hard time being approved. There have been other RFCs before that would really help the language to evolve and if this fails to be implemented into the language I think we should really reconsider the whole RFC process.
