Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129528
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 03 Dec 2025 13:31:54 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <718e4397-831b-4f05-98a7-281983692ec4@app.fastmail.com>
In-Reply-To: <0a420330-787f-4d1a-adb0-ab5ba52dd62a@app.fastmail.com>
References: <87e9d1bf-e407-45c1-9fad-d8759405ab8b@app.fastmail.com>
 <c1b032f2-95cf-46a0-9ff2-33ed3476e357@app.fastmail.com>
 <0a420330-787f-4d1a-adb0-ab5ba52dd62a@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 Wed, Dec 3, 2025, at 10:41 AM, Rob Landers wrote:
> On Wed, Dec 3, 2025, at 16:51, Larry Garfield wrote:
>> Thanks, Rob!  This does seem like a good low-hanging fruit piece to a=
ttack.  Most importantly, I don't see anything here that would preclude =
more formal TypeDef structures in the future.
>>=20
>> A few other notes:
>>=20
>> - Should `mixed` be allowed as in an alias definition?  Since `mixed`=
 matches anything, it would render the entire alias redundant as it's th=
en equivalent to `mixed`.
>
> This is already a compiler error: "Type mixed can only be used as a=20
> standalone type." That being said, I guess this could be used to renam=
e=20
> "mixed" to something else, but I don't know why you'd want to do that.=20
> I'd be open to throwing it in with "never" and "void", but "mixed" is=20
> an actual type that can be returned, which is why it wasn't.

Since it would never be meaningful, I would agree with tossing it into t=
he no pile with never and void.

>> - The "include type" syntax implies that it would not be possible to =
pre-load aliases via Composer autoload or opcache preloading.  (Well, ma=
ybe the latter.)  That feels like an unnecessary limitation, and is my m=
ain issue with the current design.  Some way to have project-wide or pac=
kage-wide definitions would be very helpful, without needing a manual in=
clude statement in every file.
>
> Currently, we don't have packages or even "real" namespaces, so as muc=
h=20
> as I'd want this, there'd need to be some settling on what authority a=20
> namespace really has. The amount of pushback that I got on the=20
> namespace-private RFC indicates to me that people don't want namespace=
s=20
> to have any authority, but they want "packages" but nobody knows what =
a=20
> package is ... but clearly, namespaces aren't anything.
>
> I digress. Sadly, no, this isn't possible with the current design. Tha=
t=20
> doesn't mean it can't be possible in the future, though, with some=20
> autoloading overhaul or changes (see: Gina's Core Autoloading RFC unde=
r=20
> Drafts). But currently, it has to pull off some shenanigans to compile=20
> the file in the file (instead of during runtime like require and=20
> include). Hence why type-files may only contain types and no other cod=
e.
>
> Basically, we just have to have some way to tell the compiler "also=20
> include these type aliases when compiling this file" -- that could be=20
> "every file from here on out gets the aliases" (ie, a `use global type=20
> float|int as Number` -- or something like that), or "include this type=20
> file" into this source file.
>
> The former would work best with today's current autoloader, but it=20
> would be "trapped" in that paradigm and would make it harder to=20
> eventually create a "type autoloader". I could be wrong, though, and=20
> I'm open to other people's ideas and opinions. I don't like the curren=
t=20
> implementation very much, and while the former is much simpler to=20
> implement, I'm reasonably confident the current implementation can be=20
> improved.
>
>> - Does it matter where the `include type` statement goes?  Must it be=
 at the top under the `use` statements, or could it be anywhere?
>
> It's basically a "copy this file right here", so it doesn't need to=20
> necessarily be at the top, but trying to include it in a function woul=
d=20
> create a syntax issue. I should clarify this in the RFC.

Since `use` statements have to be before any executable code, doesn't th=
at therefore imply that the `include type` directive must go there as we=
ll?

Which then leads me to asking if we shouldn't just use `use` for that as=
 well.  Something like:

use type string|Stringable as Stringy;
use types /some/file/here.php; // Pull in all the types from this file.

Might that help with the autoloading issues?  (I dunno, just thinking al=
oud here.)

>> - Not allowing `use` statements in type include files: This feels lik=
e a very unfortunate limitation.  Is there any way to obviate that?  It'=
s all compile time, as you said...
>
> I had to go make sure I didn't have a typo in there. I assume you mean=20
> namespaces? Namespaces in type files have a very weird problem once=20
> they get included. For instance, namespaces are also compile-time=20
> prefixes, and using statements are per namespace, not per file. By=20
> eliminating the namespace, it becomes unambiguous that it=E2=80=99s pe=
r-file.=20
> That prevents shenanigans like:

No no, I'm talking about use statements.  One of the examples you show i=
s:

// types.php - correct usage
use type \App\Models\User|\App\Models\Admin as AuthUser;

Which... eew.  I totally understand not allowing a namespace declaration=
 in the type file, but it would be much nicer to be able to type:

<?php

use App\Models\User;
use App\Models\Admin;

use type User|Admin as AuthUser;

That's what I'm talking about.

--Larry Garfield