bikeshed: Typed Aliases

Aliases can then be used only in parameter, return, property, and instanceof types. Extends and implements are out of scope entirely.

Is there a strong technical reason why extends and implements should be
out of scope?

There is definite utility for this, to create a local alias in a
namespace that can be used throughout the namespace rather than having
to refer to the external namespace in many different places.

Because it quickly can produce nonsensical syntax.

class A {}
class B {}

typealias AB: A|B;

// This is logically nonsensical.
class C extends AB {}

While there are edge cases where that might be logical (if A and B are interfaces and &-ed together, then it's kinda sorta the same as C implements A, B), separating those out and allowing just that subset sounds like a lot of work for dubious gain, and introducing surprise inconsistency. Better to just avoid that entirely.

--Larry Garfield

Aliases can then be used only in parameter, return, property, and instanceof types. Extends and implements are out of scope entirely.

Is there a strong technical reason why extends and implements should be out of scope?

There is definite utility for this, to create a local alias in a namespace that can be used throughout the namespace rather than having to refer to the external namespace in many different places.

I would very much prefer to either go all in with an Enum-like (which means that we can hang methods on to the value) or we need to distinguish between type hints for class-likes and type hints for not-class-likes (*Bar anyone?).

Allowing methods also have definite value as most use-cases I have seen in other languages alias in order to add methods, especially for enabling support of interfaces.

Which, however, brings up an important distinction that other languages have made and which I think PHP would benefit from addressing:

1. Type Alias => Different Name for Same Type
2. Type Def => New Type which has all the same properties and methods of other type

e.g. (being hypothetical with the syntax; bikeshed away):

typealias LocalWidget: Widget

typedef MyWidget: Widget {
function foo() {...}
}

function doSomething(Widget $widget) {...}

$w = new LocalWidget;
doSomething($w); // This works, no problem as LocalWidget === Widget

$w = new MyWidget;
doSomething($w); // This throws an error as MyWidget !== Widget

-Mike

Hey Mike,

Keep in mind there is already single-class aliasing with well-known behavior for both local and project-wide aliases. Local aliases are done through 'use' statements, and project-wide aliases can be created by using the class_alias() function.

I feel like any aliasing for primitive/intersection/union types should feel like an extension of that for local aliases. For 'project-wide' aliases, I'm open to much more different syntax, like typealias or even 'alias'.

As far as extends/implements go, I plan to keep it the same for simple class aliases as there is utility there and the RFC already covers this.

— Rob

My main struggle with this is readability. As much as I want custom
types (and type aliases is a good chunk of the way there), the main
issue I have is understanding what the valid inputs are:

function foo(Status $string): void { }

How do I know that Status is a) not a class, b) that I can fulfill the
requirement with a string, and/or maybe any object with __toString(),
or maybe it’s ints? Or objects or enums?

Even with file-local aliases (which I would definitely prefer to avoid)
we will most likely rely on developer tooling (e.g. IDEs and static
analyzers) to inform the developer what the right input types are.

I would very much prefer to either go all in with an Enum-like (which
means that we can hang methods on to the value) or we need to
distinguish between type hints for class-likes and type hints for
not-class-likes (*Bar anyone?).

Expanding on type-class-likes: within the type methods, $this->value
would refer to the original value, any operators would follow the
same rules as either the original values type (e.g. $int = 4; $string
= “foo”; $int . $string == “4foo", or call __toString() in all the
normal places for strings if defined).

type Stringable: string|int {
public function __toString(): string
{
return (string) $this->value; // original value
}

 // Add Stringable methods here

}.

Methods on typedefs was the sort of "other stuff classes do" that I was trying to avoid getting into right now. :-) Mainly because I can totally see how it's tempting, but also have no idea what it would mean from a type-theoretic perspective. It would only make sense if we're talking type DEFs, not type ALIASes. I'm not against that, and it could be fun to try and think through the type theoretical implications, but I don't think that's what Rob was going for so I didn't want to take that side quest just yet. (Though if he's OK with it, I'm OK with it.)

To be fair, I should probably mention that I've already explored it some (which I alluded to in another thread a couple of weeks ago). 😉 So... I guess it is 'on-topic' for no other reason than it is interesting.

Here are my notes thus far:

Sugary Generics

Since we could attach behaviors (at least at the engine level) we could use this to implement generics. Imagine we have a Box<T> and want to instantiate a Box<int|float>. To do this, when we define a Box<T>, we actually define an alias internally.

This is what the definition of our generic box class in PHP might look like:

class Box<T> { public T $var; }

It would get compiled to something like this (though it would probably be invalid php, it perhaps illustrates my meaning):

class Box {
public BoxT $var;
public function __construct(private alias BoxT) {}
}

Then, to instantiate a Box<int|float >, the engine compiles the constructor, passing the types as arguments (still probably not ever valid php) and stealing a bit from python's "self":

$box = new Box<int|float>; // compiles to $box = new Box(alias int|float);

The beauty of this is that it automatically becomes an error if you forget the type argument (and if we made it the last argument, would allow setting default values for BC reasons like Collection<T = mixed>)

Even constraints on T could be expressed similarly:

class Box<T: int|float> { public T $var; }

which may get compiled into this not ever valid php:

class Box {
public BoxT $var;
private alias BoxTConstraint => int|float;
public function __construct(private alias BoxT) {
if (BoxT is not a BoxTConstraint) throw new RunTimeException();
}

Basically, it just needs to check that the BoxT alias is of the right type during construction, essentially making generics just a sugary layer over aliases.

Ambitious Type System Replacement

I've also explored it in the case of types, in general, by replacing the entire type system with this way of representing types (where a special class represents a real type of value and its behavior). This would allow for defining casting rules, operators, passing types as values (for pattern matching), etc on types themselves. I have no idea what that would look like "at scale", but it is interesting to think about because primitive types would have the same way of working as classes and everything else. It would also separate types from their implementation—whether we want to expose this to user-land is a different story.

I suspect this could be a 'technical-only' change and not affect user-land at all. zvals would probably get a lot simpler though...

I generally stop myself from thinking too much about it, because while interesting, it is a TON of work. Not that I'm afraid of doing that work, I just don't want to do it by myself. So, I'm cautiously optimistic as a >=9.0 type thing and finding the right people/support. I have no idea how to do that, but I can at least try.

Constraints

Another exploration is that it would potentially allow for setting some constraints on raw values:

alias EmailAddress => string {
if (!is_valid_email($value)) throw new RuntimeException('not a valid email address');
}

However, I think there is a better solution for that (classes/structs/records/etc)... except for

Typed Literals

This could easily allow typed literals for value types. After all, a typed literal can be expressed as an alias over a type with a constraint.

The Hammer and Screw Problem

There are probably other use-cases by making the type-system more 'class-like', but I will say that PHP's class-system is quite robust—if not as robust as its arrays—and should probably be relied on more. That being said, I've been working through this for a bit now, and it seems that I might be wielding this as a hammer and seeing nails everywhere, even when they are screws. So, while interesting, in many cases, it probably isn't the best way to do things.

— Rob

My main struggle with this is readability. As much as I want custom
types (and type aliases is a good chunk of the way there), the main
issue I have is understanding what the valid inputs are:

<snip>

Methods on typedefs was the sort of "other stuff classes do" that I was trying to avoid getting into right now. :-) Mainly because I can totally see how it's tempting, but also have no idea what it would mean from a type-theoretic perspective. It would only make sense if we're talking type DEFs, not type ALIASes. I'm not against that, and it could be fun to try and think through the type theoretical implications, but I don't think that's what Rob was going for so I didn't want to take that side quest just yet. (Though if he's OK with it, I'm OK with it.)

I 100% agree, but I think type DEFs are something we need to consider before implementing ALIASes so that we don’t block one with the other.

So, with that in mind… I’d also like to open up the ability for Enums
to be fulfilled by the backed value, that is:

This is

1. Off topic for type aliases.
2. Has been discussed numerous times before. Enums are not equivalent to their backing value. The backing value is a standardized-serialization value. Nothing more. A string-backed enum is not a string, and a string is not a string-backed enum. Trying to use an enum as transparently equivalent to its backing value is a categorical error and belies a misunderstanding of what Enums are.

1. It’s on-topic insofar as it’s a potential option for a type hint, and therefore could cause confusion
2. I do understand this, but I also see that what will happen is a million instances of:

typealias StatusValue: Status|string;

function (StatusValue $status): void {
$status = is_string($status) ? Status::tryFrom($status) : $status;
}

Possibly with a try/catch around it too if you want a custom exception to be thrown.

And yes, I know you can just do this today:

function (Status|string $status): void {
$status = is_string($status) ? Status::tryFrom($status) : $status;
}

In reality, if we have type DEFs, we’ll probably see a typedef for every backed enum that encapsulates this behavior, so why not just allow it on the enum itself?

My point is that if you talk about type DEFs, you now have this feature where you can input one type and get something that encapsulates it, and it seems weird that enums would LOOK similar In type hint usage and function differently.

Again, I’m mostly concerned about the cognitive overhead of type ALIASes AND type DEFs if they indistinguishable from classes and enums when looking at a function signature and trying to call it without the assistant of advanced auto-complete. At the very least,
It should be clear that there is somewhere else I have to look to understand what the possible inputs are, and would like to again point to the possibility of distinguishing the use of type ALIASes (and/or DEFs) in type hints:

public *StatusValue $status;

function (*StatusValue $status): *StatusValue { }

etc.

• Davey