Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126898
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 21 Mar 2025 10:51:20 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <8cb36524-1f3d-49d6-9d7d-687bd3897a97@app.fastmail.com>
In-Reply-To: 
 <CALaXqqTS_dTWBzT6i7ACjB7yo_1ZQ4WywNzV0yZwi=4emZ0Gxg@mail.gmail.com>
References: 
 <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
 <3e35cd25-c851-4ecc-8a1b-102dadb226e5@app.fastmail.com>
 <CALaXqqTS_dTWBzT6i7ACjB7yo_1ZQ4WywNzV0yZwi=4emZ0Gxg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Mar 20, 2025, at 6:02 PM, Daniel Scherzer wrote:
> On Thu, Mar 20, 2025 at 4:00=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>> I have a use case for this in Serde, so would be in favor.
>>=20
>> We should not block this kind of improvement on the hope of generics.=
  Worst case, we have this plus generics so you have options, how terrib=
le.
>>=20
>
> Would you mind sharing details of your Serde use case? It seems that=20
> the BackedEnum example might not have been the best (since it is for=20
> static methods) and so perhaps a userland case where this would be use=
d=20
> would help.
>
> --Daniel

Simplified example to show the thing we care about:

I have an interface Formatter, like:

interface Formatter
{
    public function serializeInitialize(ClassSettings $classDef, Field $=
rootField): mixed;

    public function serializeInt(mixed $runningValue, Field $field, ?int=
 $next): mixed;

    public function serializeFloat(mixed $runningValue, Field $field, ?f=
loat $next): mixed;

   // And other methods for other types
}

The $runningValue is of a type known concretely to a given implementatio=
n, but not at the interface level.  It's returned from serializeIntializ=
e(), and then passed along to every method, recursively, as it writes ou=
t an object.

So for instance, the JSON formatter looks like this:

class JsonSerializer implements Formatter
{
     public function serializeInitialize(ClassSettings $classDef, Field =
$rootField): array
    {
        return ['root' =3D> []];
    }

    /**
     * @param array<string, mixed> $runningValue
     * @return array<string, mixed>
     */
    public function serializeInt(mixed $runningValue, Field $field, ?int=
 $next): array
    {
        $runningValue[$field->serializedName] =3D $next;
        return $runningValue;
    }
}

Because JsonFormatter works by building up an array and passing it to js=
on_encode(), eventually.  So $runningValue is guaranteed to always be an=
 array.  I can narrow the return value to an array, but not the paramete=
r.

The JsonStreamFormatter, however, has a stream object that it passes aro=
und (which wraps a file handle internally):

class JsonStreamFormatter implements Formatter
{
    public function serializeInitialize(ClassSettings $classDef, Field $=
rootField): FormatterStream
    {
        return FormatterStream::new(fopen('php://temp/', 'wb'));
    }

   /**
     * @param FormatterStream $runningValue
     */
    public function serializeInt(mixed $runningValue, Field $field, ?int=
 $next): FormatterStream
    {
        $runningValue->write((string)$next);
        return $runningValue;
    }
}

Again, I can narrow the return value but not the param.

To be clear, generics would absolutely be better in this case.  I'm just=
 not holding my breath.

Associated Types would probably work in this case, too, since it's alway=
s relevant when creating a new concrete object, not when parameterizing =
a common object.  If we got that, I'd probably use that instead.

Changing the interface to use `never` instead of `mixed` would have the =
weakest guarantees of the three, since it doesn't force me to use the *s=
ame* widened type on serializeInt(), serializeFloat(), serializeString()=
, etc., even though it would always be the same.  But it would allow me =
to communicate more type information than I can now.

How compelling this use case is, I leave as an exercise for the reader.

--Larry Garfield