> >> I would also personally prefer associated types: ... This at least lets you >> ensure the "other point" is the same type in both functions, though >> personally, I'd rather just have generics. > > I'd also like to have generics, but that isn't something I can implement > myself. Associated types would be interesting, but I don't think that > associated types would remove the entire use-case for `never` parameters, > just perhaps the specific example of BackedEnum. > > ---- > - Daniel
Heh, this is the long game I am playing with inner classes: https://externals.io/message/125049#125057 If inner classes can be implemented, then we are just a short hop from being able to implement generics with a similar approach to what I outlined in that thread. Granted, I'm making some major changes to the RFC at the moment and the implementation -- based on feedback, so it'll be a few days before that is finished. An inner class view of generics (as opposed to the type aliasing view in that thread) looks something like this: // Box<T> class Box { public class T {} // store(T $item) public function store(static:>T $item) {} } // new Box<ItemType>() $box = new class() extends Box { public class ItemType as T {} }; -Ish. Note that the example won’t actually work; but it illustrates how the engine could implement it if there were inner/nested types. So, assuming this new implementation I’ve been working on is waaay better than the old one (I think it is), and the RFC is accepted; we may be closer to generics than you thought. Or maybe there is someone out there with a whole different way of doing it that is even better… This is the approach I'm chasing though. — Rob
