MLIR type system is not limited to standard types. If they don’t suit your needs, and there are no other types that suit your needs, consider proposing and implementing your own. In this specific example, the LLVM dialect does support opaque named structs since my RFC was implemented. It can be used as a blueprint for implementing other opaque and delayed-initialization types.
Memref is not a pointer and was not really intended as such. There is no standard pointer. I would be interested in a proposal for one.
This heavily depends on the use cases so I took the “non-opinionated” option common to the rest of MLIR infra. One use may want to automatically merge opaque and non-opaque types with the same name (e.g., linker). Another use may want to automatically rename conflicting names (e.g., sequential processing of multiple unrelated modules in a context). A third one may want to just complain (e.g., linter). MLIR infra should support all of them, but I am not aware of any use case struggling with this right now, so thinking about infrastructural support for a specific case or cases sounds premature.
I will be happy to see a better proposal motivated by a use case.
Why? MLIR allows one to mix types and operations from different dialects, so I don’t really see the problem. Standard types are not really special except for shorter syntax and some legacy APIs.
Again, MLIR allows for and encourages mixing different dialects. In a neighboring thread happens a discussion on whether to split the standard dialect into pieces and how. Feel free to chime in.