Apologies for the top post, I'll... have to get used to that. > I could see implicit interfaces working in conjunction with extension functions, if we can figure those out. I'm not sure if they offer much value without them, given the state of PHP. It would basically mean you have to opt-out of a type rather than opt-in, as now. That could get... weird.
I'm not sure I understand why the value on this is low without extension functions or why we would need the ability to opt-out. In my day to day, I saw this most commonly being utilized for: 1) I'm working with a class that is probably oversized, but I only care about a thin part of the functionality, but I don't have a clear way to add an interface to that class which defines the contract I need. Using an implied interface in this case helps me thin out the contract to what I need, and that makes testing much easier as I can mock only those relevant functions. This would be resolvable with the original class being better designed, but that's not always an option. On the testing side this is kind of made easier with partial mocks, but those can trigger all sorts of side effects that aren't much fun to work with in my experience. 2) The joining of common interfaces for easier introduction of interoperable interfaces, thinking about PSR-11 not tackling the configuration of entities, or how some of the interfaces look on the symfony cache packages. 3) Clearer definition of "duck-typing" like behaviors into the function signature. This is stuff we already see in PHP (`if (method_exists(<bla bla>)`), but to me it would improve clarity if these requirements were in the parameter and property definitions, instead of in the function body. All 3 of these (at least to me) seem improved with this path and high value, but I'm worried I may be missing something. To me in these cases, if someone bumps into mistaken typing, that's generally on the caller. Explicit interfaces do guarantee that anyone opting into that contract is doing it for the intended reasons, but if you're working with an implicit interface it becomes the function caller's responsibility to ensure they are making wise decisions on what gets passed in. I don't think this is a new problem set since it exists with the current duck typing patterns, all we've done is more clearly defined our expectations on what functions exist without a lot of manual `method_exists`/`property_exists` - Spencer
