Re: [RFC] Type Aliases

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 attack. Most >> importantly, I don't see anything here that would preclude more formal TypeDef structures in >> the future. >> >> A few other notes: >> >> - Should mixed be allowed as in an alias definition? Since >> mixed matches anything, it would render the entire alias redundant >> as it's then equivalent to mixed. > > This is already a compiler error: "Type mixed can only be used as a > standalone type." That being said, I guess this could be used to rename > "mixed" to something else, but I don't know why you'd want to do that. > I'd be open to throwing it in with "never" and "void", but > "mixed" is > 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 the 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, 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 package-wide definitions would be very helpful, without needing a manual include statement in >> every file. > > Currently, we don't have packages or even "real" namespaces, so as much > as I'd want this, there'd need to be some settling on what authority a > namespace really has. The amount of pushback that I got on the > namespace-private RFC indicates to me that people don't want namespaces > to have any authority, but they want "packages" but nobody knows what a > package is ... but clearly, namespaces aren't anything. > > I digress. Sadly, no, this isn't possible with the current design. That > doesn't mean it can't be possible in the future, though, with some > autoloading overhaul or changes (see: Gina's Core Autoloading RFC under > Drafts). But currently, it has to pull off some shenanigans to compile > the file in the file (instead of during runtime like require and > include). Hence why type-files may only contain types and no other code. > > Basically, we just have to have some way to tell the compiler "also > include these type aliases when compiling this file" -- that could be > "every file from here on out gets the aliases" (ie, a `use global type > float|int as Number` -- or something like that), or "include this type > file" into this source file. > > The former would work best with today's current autoloader, but it > would be "trapped" in that paradigm and would make it harder to > eventually create a "type autoloader". I could be wrong, though, and > I'm open to other people's ideas and opinions. I don't like the current > implementation very much, and while the former is much simpler to > implement, I'm reasonably confident the current implementation can be > 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 > necessarily be at the top, but trying to include it in a function would > create a syntax issue. I should clarify this in the RFC. Since use statements have to be before any executable code, doesn't that therefore imply that the include type directive must go there as well? 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 aloud here.) >> - Not allowing use statements in type include files: This >> feels like 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 > namespaces? Namespaces in type files have a very weird problem once > they get included. For instance, namespaces are also compile-time > prefixes, and using statements are per namespace, not per file. By > eliminating the namespace, it becomes unambiguous that it’s per-file. > That prevents shenanigans like: No no, I'm talking about use statements. One of the examples you show is: // 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