Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125481
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
In-Reply-To: <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com>
Date: Mon, 9 Sep 2024 14:41:16 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4C7A7F27-B787-44CA-B664-CEF4B9B412FB@newclarity.net>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
 <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
 <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
 <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
 <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com>
 <D95D21CE-45AB-487A-B59D-40305C0C569D@rwec.co.uk>
 <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: mike@newclarity.net (Mike Schinkel)

> On Sep 7, 2024, at 4:36 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> The other direction is:
>=20
> typedef UserId: int;
>=20
> UserID is now an object that consists of just an int, but can be type =
checked against.  What's unclear is if you can do other int-y things to =
them (add, subtract, etc.), or if it's really just a shorthand for

Referencing prior art (e.g. Go) PHP could allow int literals =E2=80=94 =
e.g. `1`, `47`, etc. =E2=80=94 to be passed to typedefs derived from =
ints but require int variables to be typecast to the required type. Same =
for string literals. =20

In Go you cannot add or subtract on a typedef without casting to the =
underlying type.  I would definitely prefer that to be relaxed, but only =
if it is relaxed via an explicit opt-in, e.g. something maybe like this:

typedef UserId: int operations: +, -, *, /;
typedef UserName: string operations: .;

Or less cryptic:

typedef UserId: int operations: add, subtract, multiply, divide;
typedef UserName: string operations: concat;

Going with the named operations would allow other operations to be =
opt-in in the future, but would call into question defining operations =
as a first-class language element.

> readonly class UserId {
>  public function __construct(public int $value) {}
> }
>=20
> I could see an argument for either. =20

Typedefs enable a developer to write more robust code that they =
currently cannot do, whereas typealiases are really just syntax sugar, =
albeit sugar that probably tastes really good.

Said more explicitly, I would prefer both but if it is has to be only =
one to start, I would prefer starting with typedefs.

> Though that opens up all kinds of interesting questions about a =
typedef based on another typedef, if that's a form of inheritance or =
not, etc.  Again, I'm not sure if Rob wants to go there or not, but it's =
a place my brain has gone before. :-)

Given that a typedef can always just reference the original type(s) =
rather than basing a typedef on another typedef I would err on the =
conservative side and say initially no typedef of a typedef.=20

The current downside would be that a complex union typedef defined in =
one namespace could not easily be referred to in another namespace =
without repeating the union typedef.  Whether that would become a =
frequent problem remains to be seen so it could wait for a future RFC if =
so.

Another limit would to the workaround would be if a typedef is defined =
as private for a namespace. This as namespace-private is not currently =
possible we could cross that typedef-on-a-typedef bridge on a future day =
if namespace-private ever becomes possible. #jmtcw


> We may want to focus just on aliases for now, but design them in such =
a way that they do not cause an issue for typedefs in the future.  (Eg, =
using the `typealias` keyword instead of just `type`.)

Another option is to use a different syntax:

type MyNewType: Foo
type MyAlias =3D Foo

Not arguing for or against any specific syntax, just pointing out that =
there are other potential options.

-Mike=