Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117538
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2D889117-67BF-45E6-BD8B-321D7720B21C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Message-ID: <280B4771-81A8-44DE-9709-A4657520595C@newclarity.net>
Date: Sun, 17 Apr 2022 00:48:43 -0400
To: PHP internals <internals@lists.php.net>
Subject: Constraints vs. values as types?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_2D889117-67BF-45E6-BD8B-321D7720B21C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi PHPers,

As I have been following the discussion about the need for a "true" type =
to allow documenting that a function should only be able to return true =
vs. bool 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 before.

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 because I am mostly doing Go programming now and constraints is =
effectively how Go handled an equivalent conundrum for the Generics they =
just added.

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 side are expressions (I was just spitballing the syntax; other =
syntaxes or even concept names might represent this concept better):

	constraint true: true

	constraint false: false

If we had constraints in PHP we could also have things like this:

	constraint Truthy: !empty($this)

	constraint Falsey: empty($this)

	constraint Percent: is_numeric($this) && 0 <=3D $this && $this =
<=3D100

	constraint DateTimeable: is_object($this)
		&& (get_class=3D($this) =3D=3D DateTime::class || =
get_class=3D($this) =3D=3D DateTimeImmutable::class)

	constraint ProductID: is_string($this) && strlen($this)=3D=3D10=20=

		&& preg_match("#[A-Z]{2}[0-9]{8}#",$this)

With the above, we could write functions like this and know they are =
more "type safe" than otherwise:

	function product_exists(ProductID $product_id):bool {...}

Constraints could also be limited to using only standard library =
functions so that it would be possible to do static analysis on a =
constraint.  Clearly 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 true with a type. =20

FWIW I am just offering up an approach that seems to have worked well in =
Go for consideration. If you like it, please discuss it. If not, it was =
worth a try.

-Mike

P.S. I am sure there are many ways to improve what I proposed.  Note =
this is *just* a straw man proposal; please offer suggestions for =
improvement.


--Apple-Mail=_2D889117-67BF-45E6-BD8B-321D7720B21C--