I don’t see a good way of doing this - type objects are not extensible by design (and we care a lot about their size, since they are immortal). If you need a parallel data structure for MLIRContext, you can keep track of it next to your MLIRContext instead of inside of it.
This is one of the challenges of MLIR being extensible - we need to be able to allow library based extension without a centralized numbering authority. The current solution for this is mlir/Support/TypeID.h which provides a unique pointer for each C++ subclass. The internals of which boil down to having the linker unique C++ global variables:
template <typename T>
static TypeID get() {
static TypeID::Storage instance;
return TypeID(&instance);
}
This allows you to implement dyn_cast on types in terms of TypeID, but isn’t super efficient, particularly for range based subclasses.
In the case of MLIRSwift, I think that a properly typed protocol based approach will require us to have a “pointer to pointer map” next to MLIRContext that is lazily populated based on TypeID. This is not going to be incredibly efficient, but is the best we can do.
The other alternative is to directly ape the C++ API and have our own dyn_cast etc functions. This won’t be as nice as using as? but would have the same performance characteristics.
-Chris