[Mlir-commits] [mlir] [MLIR][Python] Make init parameters follow the field definition order (PR #186574)

[Rolf Morel]

================
@@ -23,12 +23,12 @@ class MyInt(Dialect, name="myint"):
 
     class ConstantOp(MyInt.Operation, name="constant"):
         value: IntegerAttr
-        cst: Result[i32]
+        cst: Result[i32] = infer_type()
 
     class AddOp(Operation, dialect=MyInt, name="add"):
         lhs: Operand[i32]
         rhs: Operand[i32]
-        res: Result[i32]
+        res: Result[i32] = infer_type()
----------------
rolfmorel wrote:

```suggestion
        res: Result[i32] = result(infer_type=True)
```
I am still thinking about syntax like this.

The main benefit is that it would extend to supporting 
```python
res: Result[i32] = result(infer_type=True, kw_only=True)
```
which would mean `res` occurs after the `*` in the constructor, and
```python
res: Result[Any] = result(default_factory=lambda: F32Type.get())
```
where any type is allowed though if you don't provide any it will use `f32`, and
```python
res: Result[i32] = result(infer_type=True, init=False)
```
to make it so that there is no (kw) argument `res` on the constructor.

Note that the above suggestions come from what's supported on the `field()` method on `@dataclass` from the stdlib. If I understand correctly, the `dataclass_transform` mechanism is set up to understand these keywords on alternative fields specifiers such as `result()`.

If the Python Typing community would clarify their spec, it might also allow us to just write `res: Result[i32] = result()` where `result(...)` has `infer_type=True` as a default arg. Admittedly, `res: Result[i32] = infer_type()` or `res: Result[i32] = result(infer_type=True)` is probably clearer as to the intended meaning.

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