Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115729
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAKuGYLSMY3WeUPe+LOBB_nSn3u-C_Pk3cnh0KDeKsSkjA7bTFQ@mail.gmail.com>
Date: Sat, 14 Aug 2021 19:12:56 +0200
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <39B2655D-3877-41C1-9112-E2772E44544D@gmail.com>
References: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
 <CAKuGYLSMY3WeUPe+LOBB_nSn3u-C_Pk3cnh0KDeKsSkjA7bTFQ@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Never For Argument Types
From: claude.pache@gmail.com (Claude Pache)



>=20
> On Fri, 13 Aug 2021 at 19:27, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
>=20
>> Hey internals,
>>=20
>> I've been working on the draft for my operator overloading RFC, and =
in
>> doing so I encountered a separate change that I would like to see.
>>=20
>> That is, the use of `never` as an argument type for interfaces. Since
>> arguments in PHP are contravariant to preserve Liskov substitution, =
`never`
>> as the bottom type should indicate that implementing classes can =
require
>> any type combination they want. This is in fact consistent with type =
theory
>> and set theory, and is how the bottom type is treated in several =
other
>> languages.
>>=20
>> In this case, the bottom type would be used to indicate covariant =
parameter
>> polymorphism while not conflicting with LSP.
>>=20
>> This would provide a sort of minimal form of generics to PHP without =
the
>> issues that actual generics present from an implementation =
perspective. It
>> would not, however, restrict or hinder any future RFC for generics.
>>=20
>> This is at the first draft stage, and I currently have the RFC on a =
github
>> repo to allow for easy contribution and collaboration.
>>=20
>> Any feedback is greatly appreciated.
>>=20
>> https://github.com/JordanRL/never-argument-type
>>=20
>> Jordan
>>=20


> Le 14 ao=C3=BBt 2021 =C3=A0 18:19, Matthew Brown =
<matthewmatthew@gmail.com> a =C3=A9crit :
>=20
> Hey!
>=20
> Using the "never" type to require that downstream libs specify a type =
does
> not make intuitive sense to me, because the same is not true the other =
way
> (covariantly) for return types.
>=20
> The existence of a "never" type on an overriding method does not =
require
> that upstream libs specify a return type =E2=80=94 this is perfectly =
valid:
>=20
> class A {
>  public function foo() {}
> }
> class AChild extends A {
>  public function foo():never { exit; }
> }
>=20
> Best wishes,
>=20
> Matt


Indeed, I was going to write something similar. Concretely, I assume =
that one would want to update the ArrayAccess internal interface as =
follows:

```php
interface ArrayAccess {
    public function offsetGet(never $x): mixed;
    // ...
}
```
If users of that interface would suddenly be *required* to specify a =
parameter type, whereas previously they were *forbidden* to specify one, =
except a meaningless `mixed`... it would be not nice and useless.

Moreover, note that `mixed` was only introduced very recently, in 8.0: =
so that, it would be impossible to implement `ArrayAccess` on code that =
work both in 7.x and a future version with the updated interface. Not =
only would it be not nice, but it would be positively harmful.


=E2=80=94Claude