bikeshed: Typed Aliases

On Sat, Sep 7, 2024, at 7:42 AM, Mike Schinkel wrote:

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

On Sat, Sep 7, 2024, at 14:42, Mike Schinkel wrote:

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

On Sat, Sep 7, 2024, at 15:28, Larry Garfield wrote:

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

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.

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