Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129138
Content-Type: text/plain;
	charset=us-ascii
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [PHP-DEV] Pre-RFC proposal: opt-in implicit interfaces /
 structural typing
In-Reply-To: <611bb7bf-6cb1-4fa7-bab0-9d3bdc355989@app.fastmail.com>
Date: Fri, 7 Nov 2025 14:28:38 -0500
Cc: php internals <internals@lists.php.net>,
 Spencer Malone <malone.spencer@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <467CA241-4457-4058-96D8-9CE721F22198@zort.net>
References: <CAOHeFxdVqM-q14h9BHZ5628o-sQZ-wuDv9r+BrE8Z5=h0i+ToA@mail.gmail.com>
 <83BA9524-6095-4C8B-8F82-B2F344C4D062@zort.net>
 <CAOHeFxfjsfdqb1uFV-rb4VwAAW7M4vuu+Qo-QzdRYNyJsFxcjg@mail.gmail.com>
 <611bb7bf-6cb1-4fa7-bab0-9d3bdc355989@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: jbafford@zort.net (John Bafford)


> On Nov 7, 2025, at 13:54, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> 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. =20
>=20
> 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). =20
>=20
> 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.
>=20
> --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. =46rom 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