[PoC] Associated types #18260
[PoC] Associated types #18260
Conversation
The motivation for this is that types should be considered immutable. The only times this is not valid is during compilation, optimizations (opcache), or destruction. Therefore the "normal" type foreach macros are marked to take const arguments and we add mutable version that say so in the name. Thus add various const qualifiers to communicate intent.
|
You are almost to full generics here :) ... Invariant is a good default (and usually the default for any generics). You only need a proper constraint resolver (this is partly why I was working on type trees in #18189, which would let you resolve covariant/contravariant constraints very easily). I'm working on that for zend_type the last couple of weeks -- which is far more complex. Potentially, between the two of us, we could enable something powerful here. I don't know if your intent is to get to full generics from here, but this is pretty similar to a couple of other experiments I've done. |
|
I was not really planning on going full generics. As the main issue with them from my understanding is determining the type to be bound to at runtime in a way that is not terrible for ergonomics and performance. Maybe @arnaud-lb could shed a bit more light. I didn't even think of a constraint resolver, but a few other people mentioned it and have an idea how to implement it, so will do that soon. |
Girgias
force-pushed
the
associated-types
branch
from
f72c2e6 to
2baed8a
Compare
This is a proof of concept for associated types which are resolved at compile time.
Although these are not generics, they do solve the case of template types in interfaces, as generic types bound to an interface are isomorphic to associated types.
Implementation
Depends on:
The implementation currently is very crude and basic, but it demonstrates the concept of it nonetheless.
Currently, I am forcing the associated type to be invariant, as I haven't really though about how sensible it would be to have different types and how to decide which one should be the bound one.
Having a type constraint on the associated type turned out to be relatively easy as well.
This basic PoC also does not support anything relating to an interface extending another interface that has associated types, although I have an idea how it should work.
Also no opcache/JIT support.
Benefits
This would bring somewhat better semantics for the new interfaces of my Container/Offset RFC