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
