> This feels a bit different than the class case, in that implementing > internal interfaces is common, while extending internal classes is mostly > an artifact of us not adding enough "final"s in the early days. >
I have to admit that this aspect of the feature wasn't accurately covered by RFC, sorry for that. And I agree that interface changes will imply a bit more effort to migrate; however, I believe this is for the good. For example, until a few weeks ago, probably only very few people knew what a custom SessionHandlerInterface::read() implementation should really return in case of an error: neither our stubs, nor the manual had it correctly. I "accidentally" learned about the issue (that false should be returned in case of an error) because a test failed when I was implementing this RFC. Afterwards, I fixed the return type in the stubs as well as in the documentation: https://github.com/php/php-src/pull/6884/files#diff-c6492b1d4bee1c7c3eca01e4b30af39a438ba823efa220fe1d0e5868bd58586eR74 With all that said, I am ok to have some exceptions if it turns out that a return type declaration is too disruptive for the ecosystem, but I'm hopeful that the new return types - even for interfaces - will be beneficial overall. Regards, Máté
