On Thu, 4 Dec 2025 at 00:38, Seifeddine Gmati <[email protected]> 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 <[email protected]> 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.
