Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129544
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Dec 2025 12:01:04 +0100
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Type Aliases
In-Reply-To: <87e9d1bf-e407-45c1-9fad-d8759405ab8b@app.fastmail.com>
References: <87e9d1bf-e407-45c1-9fad-d8759405ab8b@app.fastmail.com>
Message-ID: <962b89f28f16ae91db6745cb090ec1ea@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-12-02 23:23, schrieb Rob Landers:
> I’d like to request your comments on type aliases (not to be confused 
> with typedefs) at https://wiki.php.net/rfc/typed-aliases

I'm generally in favor of having type aliases available, provided that 
the design is sound. I believe there have been some discussions and 
efforts before and my understanding is that getting them to work with a 
sound design is complicated - or at least raises many edge case 
questions.

As for your RFC, I have the following notes:

1.

I also was wondering why the special `include types` syntax exists. You 
answered that in a sibling thread, but it should also be in the RFC.

2.

I feel that the `include types` syntax doesn't really fit PHP with two 
consecutive keywords without any clear delimiters to indicate that the 
second keyword effectively acts as a parameter to the first keyword.

3.

I'm seeing in the PR that `include types` must use a string literal. 
That should be mentioned in the RFC. I believe it's a significant 
limitation in the developer experience.

4.

In combination with (3), you are effectively reliant on relative paths 
to include a types file. This raises questions about what the “base 
path” is. Is it __FILE__? Is it the include_path INI? Is it the cwd?

5.

The “copy and paste” semantics of `include types` also results in 
backwards compatibility issues for libraries, because any time I add a 
new type alias to my type file, it could conflict with another type that 
the user of my library also needs.

6.

The RFC doesn't explain where type aliases work. In the RFC I'm seeing 
parameter and return type declarations. What about:

- Property Type Declarations
- The right side of `instanceof`
- `new TypeAlias()`

The latter very likely doesn't work, but what will the error message be? 
Will it be a “class not found”? Will it be “Cannot instantiate type 
alias TypeAlias”?

7.

How will type aliases appear in error messages more generally? Say I 
have:

     use type Foo|Bar as FooOrBar;

     function foo(FooOrBar $x) { }

     foo(1); // Will the error message reference FooOrBar or will it 
reference Foo|Bar

8.

What about Reflection?

9.

For nested aliases, how will that work with “DNF types”? Consider:

     use type Foo|Bar as FooOrBar;
     use type Baz&FooOrBar as BazAndFooOrBar;

This would result in `Baz&(Foo|Bar)` which is not in DNF.

----------

That's all I can think of for now, but I believe it already shows that 
there are quite a number of questions that need to be answered and I 
feel that the answers to those questions are likely not going to be 
satisfactory by either resulting in a questionable developer experience 
or by preventing a clean implementation of the future scope (e.g. 
autoloading semantics).

Best regards
Tim Düsterhus