Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125932
Feedback-ID: id5114917:Fastmail
Date: Sat, 09 Nov 2024 12:33:22 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] First-class types RFC
User-Agent: K-9 Mail for Android
In-Reply-To: <AS4P192MB162200EBAB671895CA643F3F985E2@AS4P192MB1622.EURP192.PROD.OUTLOOK.COM>
References: <AS4P192MB162200EBAB671895CA643F3F985E2@AS4P192MB1622.EURP192.PROD.OUTLOOK.COM>
Message-ID: <BB991F5D-1560-4864-AF82-600DC3DE175D@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 9 November 2024 08:39:57 GMT, Adam Kecskes <kecskes=2Eadam@outlook=2Eco=
m> wrote:
>I propose adding first-class types to PHP, as this feature could greatly =
enhance the language, especially given PHP's unique runtime type-checking s=
ystem=2E Many libraries currently rely on class strings as function paramet=
ers, which could be made significantly safer with native types rather than =
strings=2E


Hi Adam,=20

I think this is an interesting idea to think about, although I have no ide=
a what the implementation might look like=2E

One of the things I've been thinking about for some time is how to improve=
 PHP's type casting functionality, and a key sticking point is a sufficient=
ly flexible syntax=2E Not wanting to get into the casting itself, let's ima=
gine we want to add "foo casts", available for all types, including unions,=
 nullable types, etc; options seem to be:=20

- foo_cast("int|string", $value) - a "stringly typed" function with no new=
 syntax; flexible, but ugly and awkward to statically analyse=20
- foo_cast($value as int|string) - a new keyword for each type of cast; ex=
pressive, but a high barrier to adding more casting options
- foo_cast<int|string>($value) - if we add generics, even without type inf=
erence, that syntax could be used to "specialise" by type
- foo_cast(int|string, $value) - passing the type as a parameter would rea=
d very nicely

There's a lot of overlap between the last two, but also some differences:

- generics give a clear way of expressing that the function will return th=
e given type, or perhaps some manipulation of it, like "function foo_cast<T=
>(mixed $value): T|CastError"
- first-class types, on the other hand, give a clear way for userland to p=
ass around type specifications, like "function cast_in_turn(mixed $value, t=
ype =2E=2E=2E$types): array { /* loop over $types, calling foo_cast($type, =
$value) for each one */ }"

Would first-class types and generics need to be mutually exclusive, to avo=
id a confusing overlap of functionality? Or could they be made explicitly c=
omplementary somehow?

I wonder what prior art there is in this area, in both the theory of type =
systems, and the practice of language implementations?

Regards,
Rowan Tommins
[IMSoP]