Hi people, I’m quite new to zig and while doing the ziglings I encountered the following topic regarding arrays.
If Zig can infer the type of a variable like this:var test1 = 5;
And zig generally declares types like this: var test2 : u8 = 6;
And declares arrays like this: var test3 : [3]u8 = .{1,2,3};
Why can’t it infer the length in arrays like this: var test4 : [_]u8 = {1,2,3};
Wouldn’t it be most consistently looking that way? is there a logical reason for making it like this: var test5 = [_]u8{1,2,3};
?
Because I also wouldn’t declare a non array variable like this: var test6 = u8{255};
This needs a dot in front of the brace var test3 : [3]u8 = .{1,2,3};
Zig has only started to shift its focus towards the var name : type = <expr or literal that uses result location> syntax in recent versions.
That said I think [_]u8{1,2,3} makes more sense, because your hypothetical syntax would allow errors like this:
var test4 : [_]u8 = <runtime value>;
With the [_]u8 being directly in front of the array literal it is impossible to use the syntax with a runtime value, which is good because you can’t create an array with a length that is only known at runtime, the length always needs to be known at comptime.
I see… But the compiler could easily determine if the value is fixed during compile time, with checking for a [_] literal in the type and give me an error, couldn’t it?
I think it could check, but I would still say that the current syntax is easier and can be used more directly and locally, without having to do more work for slightly fancier syntax.
While I am not totally opposed to it, I think it would make the compiler implementation more complex, for no obvious benefit besides making the syntax look more regular. But I guess a compiler developer would have to say, whether that is actually true, I don’t have enough in-depth knowledge to be completely sure.
It would also require to add a new error message for something that currently just can’t be expressed, because it is not valid syntax.
From an zig beginner point of view, the current array syntax is not canonical with the declaration of other variables, which for me was worth writing this topic, because on the ziglang website it says:
“A Simple Language - Focus on debugging your application rather than debugging your programming language knowledge.”
So at some points I must seek insight, why the syntax is like it is, when I don’t understand why the syntax is not ‘simpler’.
At the moment I acknowledge the one point for the current array syntax:
I guess that is fair, but I also thought that lisp is nice simple regular syntax, while others find it to be an absolutely unreadable mess of parentheses
So overall I would say it is difficult to say what would be simple to most people or even the target audience.
Maybe someone else has another perspective/insight on the topic.
That’s true.
The sentence you just posted is a good example.
You could also have said:
“Things that are simple can still be unreadable. And also, things that are unreadable, still can be simple.”
(Now, hopefully I understood correctly )
The more we strip down a language in terms of vocabulary, the simpler we have to communicate. (But also the longer the conversation might be)
On the other hand, a vast vocabulary offers sophisticated expressions and shorthands. (But if we have have one unique word for every expression we obviously overkilled it)
I like both approaches for their respective traits.
As with many things I have the feeling that the middle-ground is the best thing.
There is a certain pleasure to decode obfuscated code or language. There is always a time in space for that.
There is also a certain pleasure in decode the meaning of something great that is comes in a clear language.
For me personally, in programming, a language should have a single way to do a unique task and it should encouraging to write simple code that is readable.
But there is only so much the language itself can do, to achieve this.
)
