[Mlir-commits] [mlir] add IntegerLikeTypeInterface to enable out-of-tree uses of built-in attributes that otherwise force integer types (PR #137061)

[Mehdi Amini]

joker-eph wrote:

> Is there a more fundamental reason why this flexibility is not desired, if those issues could be overcome?

I haven't followed  the entire discussion because River was handling it, but to me there is something more fundamental: `IntegerLikeTypeInterface` seems a very general interface which rabbit hole into the support of arith dialect, etc. 
That is if we introduce such an API this is to make the behavior of "Integer" in general in the system extensible. However you're interested only in reusing some parsing functionality, which is a very narrow use-case. 
Solving a narrow use-case is much easier and has less pitfalls than solving a very general case (which requires lot of design considerations). 

Parser/printer are also "debugging tools" in the system (a production compiler is unlikely to rely on these), so if there is something to tradeoff in a design it won't be towards parsing/printing. For example changing DenseElementAttr fundamentally just so that you can reuse a parsing function.


https://github.com/llvm/llvm-project/pull/137061