Re: [RFC] Type Aliases

On Thu, 4 Dec 2025 at 00:38, Seifeddine Gmati <azjezz@carthage.software> wrote: > > HI Rob, > > Thanks for the RFC. I’m really happy to see a proposal for typed aliases, but to be honest, I > have some major concerns about the implementation strategy, specifically the use > types mechanism. > > The proposed syntax (use types 'file.php') feels like > a step backward. We are essentially re-introducing the same autoloading pain points we currently > have with functions. I strongly believe type aliases should just be first-class citizens like > classes, interfaces, or enums, they should live in the same symbol table (so you can't have a > class User and a type User) and > follow standard namespacing and autoloading rules. > > It should look like this: > > ```php > namespace App\Aliases; > > type UserIdentifier = string|int|Uuid; > ``` > > And be used just like any other symbol: > > ```php > use App\Aliases\UserIdentifier; > > function greet(UserIdentifier $uid): void { ... } > ``` > > I also want to highlight a specific issue from a tooling perspective. I maintain a static > analyzer (Mago - https://github.com/carthage-software/mago), which > uses a multi-threaded, and has an architecture similar to Psalm. > > The use types <file> directive would be a massive > headache. If an alias is being imported from a file that was not configured in the source paths, our > analyzer would have to pause all analysis threads to fetch, parse, and index that one file and make > it available globally. This would severely impact performance and concurrency. This is not a total > blocker, and we would probably find a workaround, but it would add significant complexity and slow > down analysis for everyone. > > I recommend looking at how Hack handles this. They successfully implement > type (aliasing) and newtype (opaque > types) in a way that feels natural and integrates with the autoloader. Adopting a similar approach > type Foo = ... would future-proof PHP for potential > newtype additions later without requiring a clunky import syntax > now. > > Regards, > Seifeddine Gmati. > > On Tue, 2 Dec 2025 at 23:24, Rob Landers <rob@bottled.codes> wrote: >> >> Hello Internals, >> >> I’d like to request your comments on type aliases (not to be confused with typedefs) at >> https://wiki.php.net/rfc/typed-aliases >> >> TL;DR (it’s 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 readable and reduce >> repetition with no runtime overhead. Type aliases follow the same scoping rules as other use >> imports. >> >> — Rob Hi again! I saw that you mentioned in previous emails that implementing autoloading for type aliases isn't possible, so I wanted to verify that, I spent some time digging to see if I could get the syntax I proposed earlier working and I managed to get a working implementation. ref: https://github.com/carthage-software/php-src/tree/type-aliases This approach would resolve the static analysis issues I mentioned earlier, give us a cleaner mechanism for autoloading, and keep PHP's behavior consistent. Note that my implementation above is not complete, and would probably need to be double and triple checked. Regards, Seifeddine Gmati.