They are now equivalent to ._init_().
To make this more ergonomic, a built-in new or init function could be added.
I don’t like the current initalizer lists, since they are harder to distinguish as function calls.
Mojo has reached 1.0, time for these conversations are long gone.
I did warn that this would be unnecessary with Zig’s inferred syntax. Now we have two ways of doing the same thing. But I don’t think it’s too late. The 1.0 release for Mojo is more of a marketing move and isn’t as aggressive as Go or Rust; a 2.0 version will surely come eventually.
That things should never change, even if considered a design mistake, is not the attitude I agree with. We need innovation not stagnation
The reason this syntax exists is because TypeName.__init__() can be extremely verbose in some cases, depending on what TypeName is. TileTensor instances with complex layouts in particular are a use-case for this, where the whole point is not needing to write out the type name.
This argument does not exist anymore, since static methods can have their types inferred.
Chris also said, he prefers to use initalizer lists for long types, but not for short type names, so I am not sure what would speak against an init built-in function or .init idiom.
I generally don’t understand why init is so special. There are many weird private constructors because of this restriction.
So maybe get rid of @staticmethod and just introduce a static modifier. Or maybe just get rid of static altogether like Rust. Because custom self names don’t seem to be idiomatic unlike Go and Zig.
EDIT: So I propose to allow field initialization for every out self static method.
Python has a completely different model. And even python 3 has historic bagage. It’s always interesting to look into the history of python and the current assessment of the feature/syntax.