Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117539
Content-Type: multipart/alternative; boundary=Apple-Mail-57495BED-755F-45C0-A326-A487E2630FFB
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Sun, 17 Apr 2022 15:48:02 -0500
Message-ID: <0DB112AE-E7A7-4479-96C5-DCCC28E547A2@benramsey.com>
References: <280B4771-81A8-44DE-9709-A4657520595C@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <280B4771-81A8-44DE-9709-A4657520595C@newclarity.net>
To: Mike Schinkel <mike@newclarity.net>
Subject: Re: [PHP-DEV] Constraints vs. values as types?
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail-57495BED-755F-45C0-A326-A487E2630FFB
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

> On Apr 16, 2022, at 23:48, Mike Schinkel <mike@newclarity.net> wrote:
>=20
> =EF=BB=BFHi PHPers,
>=20
> As I have been following the discussion about the need for a "true" type t=
o allow documenting that a function should only be able to return true vs. b=
ool which would allow false, and in the past the same argument for false vs.=
 true, it occurs to me that there is another approach to address this rather=
 than add values to be types which AFAIK has not been mentioned on the list b=
efore.
>=20
> An alternate solution to possibly consider might be to add the concept of "=
constraints" to PHP that could work alongside types. This occured to me beca=
use I am mostly doing Go programming now and constraints is effectively how G=
o handled an equivalent conundrum for the Generics they just added.
>=20
> Consider if PHP allowed the following and if PHP would allow type hints to=
 use *either* a type *or* a constraint where the values on the right hand si=
de are expressions (I was just spitballing the syntax; other syntaxes or eve=
n concept names might represent this concept better):
>=20
>    constraint true: true
>=20
>    constraint false: false
>=20
> If we had constraints in PHP we could also have things like this:
>=20
>    constraint Truthy: !empty($this)
>=20
>    constraint Falsey: empty($this)
>=20
>    constraint Percent: is_numeric($this) && 0 <=3D $this && $this <=3D100
>=20
>    constraint DateTimeable: is_object($this)
>        && (get_class=3D($this) =3D=3D DateTime::class || get_class=3D($thi=
s) =3D=3D DateTimeImmutable::class)
>=20
>    constraint ProductID: is_string($this) && strlen($this)=3D=3D10=20
>        && preg_match("#[A-Z]{2}[0-9]{8}#",$this)
>=20
> With the above, we could write functions like this and know they are more "=
type safe" than otherwise:
>=20
>    function product_exists(ProductID $product_id):bool {...}
>=20
> Constraints could also be limited to using only standard library functions=
 so that it would be possible to do static analysis on a constraint.  Clearl=
y a static analyzer could evaluate the constraints I represented above. And I=
 *think* this could be backward compatible with false as a type, and even tr=
ue with a type. =20
>=20
> FWIW I am just offering up an approach that seems to have worked well in G=
o for consideration. If you like it, please discuss it. If not, it was worth=
 a try.
>=20
> -Mike
>=20
> P.S. I am sure there are many ways to improve what I proposed.  Note this i=
s *just* a straw man proposal; please offer suggestions for improvement.
>=20


This reminds me of some of the discussion we=E2=80=99ve had on list of type a=
liasing.[^1]

I really like this idea and think it could be combined with type aliasing to=
 create powerful userland-defined types.

While you mention restricting to standard-library functions for easier type-=
safety, I=E2=80=99m not sure it has to have that limitation. What we=E2=80=99=
re effectively defining here is a kind of short-hand Closure that is then ca=
lled with the passed value at runtime to validate the type. A type alias cou=
ld work similarly, perhaps even with the same syntax.

Cheers,
Ben

[^1]: https://externals.io/message/112209#112214=

--Apple-Mail-57495BED-755F-45C0-A326-A487E2630FFB--