Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129524
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 03 Dec 2025 09:51:19 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <c1b032f2-95cf-46a0-9ff2-33ed3476e357@app.fastmail.com>
In-Reply-To: <87e9d1bf-e407-45c1-9fad-d8759405ab8b@app.fastmail.com>
References: <87e9d1bf-e407-45c1-9fad-d8759405ab8b@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Type Aliases
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 2, 2025, at 4:23 PM, Rob Landers wrote:
> Hello Internals,
>
> I=E2=80=99d like to request your comments on type aliases (not to be c=
onfused=20
> with typedefs) at https://wiki.php.net/rfc/typed-aliases
>
> TL;DR (it=E2=80=99s actually rather short):
>
> Following the same syntax as other use'ing statements, you can alias a=
 type:
>
> use type int|float as Number;
>
> function sum(Number $a, Number $b): Number { return $a + $b; }
>
> You can also include types, with some restrictions:
>
> include types 'math-types.php';
>
> function sum(Number $a, Number $b): Number { return $a + $b; }
>
> These are compile-time replacements that serve to make code more=20
> readable and reduce repetition with no runtime overhead. Type aliases=20
> follow the same scoping rules as other use imports.
>
> =E2=80=94 Rob

Thanks, Rob!  This does seem like a good low-hanging fruit piece to atta=
ck.  Most importantly, I don't see anything here that would preclude mor=
e formal TypeDef structures in the future.

A few other notes:

- Should `mixed` be allowed as in an alias definition?  Since `mixed` ma=
tches anything, it would render the entire alias redundant as it's then =
equivalent to `mixed`.

- What if any conflict resolution is there if you include two different =
type files that declare the same alias?

- Because it's all compile time, I assume two aliases with the same sour=
ce but different names become compatible? =20
Eg:

use type string|Stringable as Stringy;
use type string|Stringable as Stringish;

Those are mutually compatible in practice, yes?

- Are aliases case sensitive?  You're using Capitalized names in the RFC=
, but I don't know if that means anything...  (Please state in the RFC.)

- The "include type" syntax implies that it would not be possible to pre=
-load aliases via Composer autoload or opcache preloading.  (Well, maybe=
 the latter.)  That feels like an unnecessary limitation, and is my main=
 issue with the current design.  Some way to have project-wide or packag=
e-wide definitions would be very helpful, without needing a manual inclu=
de statement in every file.

- Does it matter where the `include type` statement goes?  Must it be at=
 the top under the `use` statements, or could it be anywhere?

- Not allowing `use` statements in type include files: This feels like a=
 very unfortunate limitation.  Is there any way to obviate that?  It's a=
ll compile time, as you said...

Overall, I am tentatively in favor.

--Larry Garfield