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

The extension idea is interesting! I hadn't thought of that. Autoloading might be a PITA with that, I'm trying to think of how you would manage that? On the subject of "mistaken typing" or implicit interfaces being met by classes that don't actually do the desired behavior, I think you're right it's a risk, my counterargument is typescript and golang both have implicit interfaces in some form (well typescript calls them structural typing), but I don't think in either language I've ever really run into a case where that risk becomes a reality. I'm hesitant to declare this because I'm not sure this is the best way to frame this from a PR perspective, but in many respects this proposal is viewable as a syntax shortcut to duck typing, which is already pretty common across PHP. While there are definitely drawbacks to duck typing, it's still a very useful tool IMO (and becomes very cumbersome if you need to duck type a larger set of functions). On Fri, Nov 7, 2025 at 9:51 AM John Bafford <jbafford@zort.net> wrote:

On Fri, Nov 7, 2025, at 1:19 PM, Rowan Tommins [IMSoP] wrote:

__toString() is *old*. It may go all the way back to 5.0, but it was there at least as of 5.2. The problem is that there was no way to type against it. You could type `string`, but not `string or object that implements string`. When we got union types in 8.0, that was tempting but not yet possible. So Stringable was added basically for typing against `string|Stringable`. And it was made implicitly added because there were a bajillion __toString() functions in the wild already that shouldn't have to be modified before you could type against them. </history lesson> --Larry Garfield

On Friday 07 November 2025 20:19:37 (+01:00), Rowan Tommins [IMSoP] wrote:

Good thinking, inspiring, in my eyes that __toString() magically, both in the method as in the inverse of the direction towards the Stringable interface definition, is rather stemming from the needs of some object oriented PHP framework authors IIRC. In terms of it as a historical artifact to learn from or take something away from it for similar implicit interfaces, I'd like to add that I find it rather explicit (like a parental advisory sticker on a CD jewel case) due to the inability of PHP to resolve such (internal) interfaces at place of use (the implements keyword) while there was no problem with the implicit magic method. This is perhaps why I as well have very little understanding what that single instance has brought to the table finally, it appears to stand in the way much too often for me on the observable surface. The only hope I nevertheless had with it is, that it would have helped to solve the problem of __toString() fatalling in the engine. So Stringable/object{__toString(): string} is certainly a very special example in its very own not as a _magical_ special case, but it is a fundamental special case every programming language that has "output" has to solve. Not having any output would solve the turing problem by its higher math, but such machines also have effectively undefined themselves and by that any programming language. That problem is inherit with output and it is the formatting of output, even if it is only dumping the content of the process registers. What we can't see does not exist. So every programming language at that point must re-invent itself somehow, as it certainly does not compile recursively, but rather has the concepts of compiletime, runtime, whatnottime and the recursion, direct or indirect, often a property stemming from these, it (recursion) is always a thing, too.

Unless strict normative rules are given by the design to prevent that (e.g. to make things maintainable safely in the longtime), but every extension will add, not remove, so longtime or eternity often only remains the idea, bugs and regressions the reality along the road of success. If we take output then for a given, we have to solve this problem at its core, otherwise we can't built upon it. This is where yours mentioned implicit Stringable interface comes into play. For those Framework authors it certainly was enough to given them a way to go from a method pointer ("__toString") or a memory pointer (the string), from a memory object to a PHP language classlike object, e.g. by declaring the type with a function or method parameter (in) or return value (out). Regardless if only compiled once to its executable form, ErrorException (PHP 5.1), or as in PHP userland compiled, interpreted and re-compiled until it gets there: What do you do when that error is to be handled and the error handler is in userland (or at compile time) and includes (or has) more code to be evaluated while handling the error still on the engine level? See in PHP thanks to the scripts, we have this inane recursion problem. This is a bit like heart surgery on the open heart, the pump is still pumping and one wrong cut everything can bleed out. The doctor may survive, so in terms of software, there is not much need to really know what we are doing here and can defer some work until later. In real life this causes grave injuries if not deaths. How successful such an implicit Stringable interface (PHP 8.0 IIRC) was in this sense I do not know. I do not even know if the introduction of Stringable has been discussed afterwards in that regard. But I'm derailing, what I wanted to prolong on is, that Stringable in itself as an "implicit" interface as you have rightfully mentioned, is certainly touching many more parts than the suggested "implicit interface" by Spence Malone would need to care about. So what are other examples? Tagging (with empty interfaces) often comes to my mind then, but all interfaces, empty or not, also have the probem of the loading order in PHP. At place of use, where they would shine, requires not only to explicitly define them (good!), but also to explicitly have them loaded. So there perhaps is still a problem in PHP core to get compilation and execution into a quite better order in the sense of their arrangement to make use of the language with the runtime. The framework authors didn't had that problem, because they voided it by separating each classlike into its own file (object) and then let having PHP/SPL resolve the loading order (a.k.a. class autoloading). At the core we can still see that problem as separating each classlike into an object (file) of its own requires preproduction (those are actually deployables, so we're not programming any longer but have longtime stopped and already are building the artifacts.) If there is something to strengthen, then it is the ability of PHP developers to program in PHP, not to waste time thinking about that they need to learn some special technique how to arrange their code later on so that it fullfills some dependency, theirs dependency managers and then call that the art of doing module management. This is all longtime afterards and therefore always inherits any previous flaw at the languages core every PHP framework author intends to not address at all. So in my opinion your raise of the dynamics from explicit to implicit and vice-versa can bring interesting aspects to the table regardless which style each of us is currently thinking to prefer, but as you rightfully raised, PHP core developers should also confront themselves on how to pick up the loose ends we still have while new authors make useful suggestions to extend language-level intermediates. From PHP history, IMHO (and regardless how I use or not use them), Traits are a key milestone in this way of PHP design done right for me. The proposal aligns well for me in that regard. Stringable on the other hand, a bad example of everything but making problems in core and use of the PHP language itself more visible; and that is often a good thing, see the output problem above I mentioned, my current understanding is that we always inherit that on computer systems and when programming machines. So as long as we can get output, we can benefit. Naturally we benefit from explicit output much more then from implicit one - until otherwise.

my 2 cents, - h.k.