Re: Pre-RFC proposal: opt-in implicit interfaces / structural typing

> On Nov 7, 2025, at 13:54, Larry Garfield <larry@garfieldtech.com> wrote: > > Languages with implicit interfaces like Go also go (no pun intended) "all in" on it. > All methods on an object are defined externally, possibly not even in the same file. The whole > standard lib was built on that model from the ground up. That's not the case in PHP. > > I've been pondering extension functions for some time, and have kicked the idea around > with John before. (I would do it as functions, a la Kotlin, not as a secondary class, like Rust.) > Autoloading and efficiently determining that you need to call an extension are the key stumbling > blocks (though my stance on autoloading at this point is "we've got opcache enabled 100% > of the time, we have things like FrankenPHP, just front-load the file and move on with your life). > > 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. > > --Larry Garfield Opting out would both be weird, and from a practical standpoint, is unreasonable to ask of userspace developers. For correctness, every potential implicit interface match would have to be explicitly declared as non-comforming in order to be correct. It's both very noisy and does not scale. From a library perspective, it's impossible: a library class can't possibly declare all the possible does_not_implement conformances because the entire universe of interfaces that might overlap its shape can't be known. A pathological example might look something like: ``` class DeckOfCards implements Shuffleable, \Deck\Drawable // We don't actually import any of these, but we have to explicitly deny them because otherwise it will cause problems in end-user code does_not_implement \FooGraphics\Drawable, \BarGraphics\Drawable, \ZodGraphics\Drawable, \GameEngine\TieInterface, \BarGameEngine\DeckDrawable, \Vehicle\Drawable {...} ``` There's also a problem point with any code that calls get_declared_classes() and filters by instanceof SomeInterface. Now all that code is potentially broken (if implicit conformances don't meet contractual requirements). Would we need to add an implicit/explicit/either option to is_a() to make userspace able to correctly reason about types? Are there other cases where implicit conformance needs to be treated differently than explicit conformance? Importing a package that has an implicit type would basically have to come with a warning, "don't make your classes look like this interface or else things might break". And I'm sure someone would also find a creative way to abuse the trivial case, implicit interface AnyObject {}. -John