Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126700
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
In-Reply-To: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
Date: Mon, 10 Mar 2025 22:44:32 +0100
Message-ID: <CAPyj-LBzBkhw34hK7n9jPGyBcnzTZhTT+4-OmgF0kA5rDzh=Hg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Daniel

On Mon, Mar 10, 2025 at 8:06=E2=80=AFPM Daniel Scherzer
<daniel.e.scherzer@gmail.com> wrote:
>
> I'd like to start discussion on a new RFC about allowing `never` for para=
meter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.com/php/php-src/pull/18016

Thank you for your proposal!

I would have slightly preferred to investigate associated types first.
They mostly solve the same problem, except they can express
relationships between other parameters or return types. For example:

interface Enum {
    public type BackingType; // Potentially with `: int|float`?
    public function from(BackingType $value): static;
    public function tryFrom(BackingType $value): ?static;
}

This has a slightly more accurate signature, namely enforcing that
from() and tryFrom() take the same argument type. Furthermore, you can
use the same associated type in return types, whereas mixed would have
to be used without them. I'd also argue it's easier to understand
without deep knowledge of type systems. Associated types are similar
to what a generic interface would give you, except:

1. Every class implementing this interface can only implement it once,
restricting the associated type to one concrete type. This makes sense
for PHP, given that we don't have method overloading, which would be
required to make use of multiple generic interface implementations.
2. It's much simpler to implement than generics, given that this can
be fully enforced during inheritance rather than runtime.

I understand that associated types are still significantly more work
than a never type, so I don't mind going with this solution. Given
that BackedEnum cannot be implemented by users, migrating it to use
associated types could be done without BC breaks.

Ilija