Sorry for asking a question the answer to which seems to be a matter of pure taste, but I am curious whether there is a common guideline for it.
Is
let x = MyType(...)
preferred over
let x: MyType = .init()
To me both forms have the same information, on the other hand, when using something like VsCode for example, type hints are displayed by default, so the first form is kind of redundant.
On XCode, types aren't displayed by default, but still, there's is not much difference in clarity or brevity.
Same goes when returning variables - especially one liner functions. Against - the type is clear, so we don't lose too much readility or clarity. On the second hand, the second form is often more brief, especially when type name is long.
Is it considered a bad practice to use return .init(...) instead of return MyLongTypeName(...)? If it is - what is the rationale for it?
Both forms are perfectly acceptable and commonly used, as are several others.
Some style guides might prefer one over another in certain circumstances, and if you are working on a project or for an organization which adheres to such a guide then of course you should follow it.
But in general you are free to write whichever version you like.
Like most things style-wise, I think .init is fine in moderation, as long as folks don't make their code harder to understand by abusing it.
In isolation, something like let x: SomeType = .init() is more verbose than just let x = SomeType(), but it's otherwise harmless to readability since the type is still written there. There are folks out there who adopt policies of using explicit type annotations to improve type checking performance (more important for property types referenced across files than it is for local variables), so .init is a fine way to avoid the repetition of let x: SomeType = SomeType().
It's easy to go overboard though. Say you have an existing variable that you're assigning the result of a complex construction:
result = .init(foo: .init(bar: f(), baz: g()), quux: .init(h()))
As a reader, I would love to know what the actual types of those things are without having to jump to each definition.
As a general rule, folks shouldn't lean on IDE-specific features to rationalize whether they use certain language features or syntax, because the IDE is only one of the environments where people will be reading code. Other tools, like code review interfaces, won't have the same affordances.
I was talking in contexts where the type is obvious. (Assignments/ one liner or very short functions).
In your case it is not...
In the example you have provided I doubt that even compiler could necessarily infer the types...
It can if result has been declared elsewhere because it must have already been assigned a type. So then the compiler just has to look at which initializers it has available, find one with the right labels, determine the expected types, and so forth. As long as it reduces down to a single unambiguous solution (no overloads that are distinguished only by type, for example), it'll compile.