Fix lint diagnostics for write! inline macro

[wawel37]

The (()) is not necessary here as the type is inferred. This change is applied to the cairo-lint standards of the code. For more context see https://github.com/software-mansion/cairo-lint/blob/84709c709d339740c6781b74a09e88ddd10ded38/src/lints/redundant_brackets_in_enum_call.rs#L47

[reviewable-StarkWare]

This change is 

[orizi]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion

---

crates/cairo-lang-semantic/src/inline_macros/write.rs line 392 at r1 (raw file):

        self.flush_pending_chars(builder, &mut pending_chars, ident_count);
        self.add_indentation(builder, ident_count);
        builder.add_str("core::result::Result::<(), core::fmt::Error>::Ok\n");

only explicit unit types should be done that way.
so i don't think this should be prefered (Result::Ok is incidentally a unit type, but not in the enum itself)

[wawel37]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @orizi)

---

crates/cairo-lang-semantic/src/inline_macros/write.rs line 392 at r1 (raw file):

Previously, orizi wrote…

only explicit unit types should be done that way.
so i don't think this should be prefered (Result::Ok is incidentally a unit type, but not in the enum itself)

Are you sure about that? If it's because of the fact, that the generic types can be defined somewhere else, it's also applies to the enum being defined somewhere else. So in the end, user have to go to definition and look it up, whether it's from the explicit type or the generic one.

[orizi]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @wawel37)

---

crates/cairo-lang-semantic/src/inline_macros/write.rs line 392 at r1 (raw file):

Previously, wawel37 (Mateusz Kowalski) wrote…

Are you sure about that? If it's because of the fact, that the generic types can be defined somewhere else, it's also applies to the enum being defined somewhere else. So in the end, user have to go to definition and look it up, whether it's from the explicit type or the generic one.

WDYM the user? this should be our decision - Ok by itself seems weird to me - as in the replacement of the generic Result the definition would have been with Ok: () and not the shorthand.

in general i would expect the shorthand in usage to match a shorthand in the definition.