The related remove T{} syntax in favor of type coercion · Issue #5038 · ziglang/zig · GitHub is still open and now accepted, but get rid of the `.` in tuples & anonymous struct literal syntax · Issue #5039 · ziglang/zig · GitHub was apparently closed as not planned.
Does this simply mean that only what was originally proposed has been rejected (i.e. just removing the . in front of {}), or is there also no hope for the other proposals discussed there, especially replacing .{} with []?
I don’t think .{} is going to be removed, but T{} might be. The dot in zig is pretty consistent when you think of it as “inherit the type from the result type”.
The accepted proposal was not for removing the dot, it was for removing the explicitly typed struct initializer form
const my_struct = MyStruct{};
and keeping type coercion from anonymous struct inits
const my_struct: MyStruct = .{};
const my_struct = @as(MyStruct, .{});
as the only way to initialize a struct.
The proposal for removing the dot from anonymous struct inits was rejected.
Yes, the dot could be thought of as representing a type that is omitted because it can be inferred. But it will make less sense when the T{} syntax is removed, because then it is not even a placeholder for anything anymore.
I don’t think it’s necessary to overthink the semantics of . in .{...}. .{...} is just a block used to express structure, and the dot in front is simply to distinguish it from code blocks without any markings. Any other symbol could be used to distinguish it from a code block; it’s just that the dot is the simplest, that’s all.
Edit: . here can be interpreted as the meaning of result type inference. This makes sense because in Zig these struct types themselves are namespaces, and we always use . as the namespace access operator. This is consistent with the perception of declaring literals.
Edit again: . can be understood as the magical character that triggers auto-completion in LSP lol, that’s really cool
pedantic but it is not coercion, it is type inference!
There used to be coercion from anonymous structs to concrete structs, but that was removed a while ago. IIRC they forgot to remove it when they planned so for a short time it was also a bug.
This is why it is currently needed, but the .{} syntax is the ugliest possible way to achieve this. And when T{} disappears, the main justification for choosing the .{} syntax is gone; the other interpretations don’t make that much sense. It is essentially legacy cruft that will be even more confusing to people learning the language in the future without knowing where it came from.
But maybe it’s better to discuss this when T{} has actually been removed, this probably solves some ambiguities. I was just shocked when I saw that #5039 was simply closed.
I initially also thought [...] was better, but I no longer think so at all, because the experience of using . is now extremely consistent: pressing . basically triggers autocomplete (with the exception of a few cases like formatted strings where the experience is inconsistent), whether accessing struct members, accessing namespace declarations, or using result type inference. If someone told me now to not use . but to press [ to trigger autocomplete, I would actually find it inconsistent.