4 ms·

I don't come from TS, but this seems like a good intro to zig from that sort of perspective. There's a whole lot of paradigms to relearn when you switch to some

I don't come from TS, but this seems like a good intro to zig from that sort of perspective. There's a whole lot of paradigms to relearn when you switch to something like Zig and this kind of content is useful. I'll nitpick with one complaint though... const values = std.AutoHashMap(Point, u32); defer values.deinit(); try values.put(Point{ .x = 0, .y = 0 }, 1); // ~~~~~~^~~~ error: expected 3 argument(s), found 2 > The mistake here isn't on that line, and it doesn't have to do with the number of arguments. Rather, it's that I forgot to call .init() on the hash map Well... >>> class MyType(): ... def test(self, a, b): return a + b; ... >>> x = MyType >>> x.test(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: test() missing 1 required positional argument: 'b' How else do you want unbound functions to behave when you haven't constructed an instance of the type yet? (And FWIW, zls in vscode correctly annotates values as having type `type` for me)

Dylan16807 2y ago
If the type is `type`, and you're missing one argument, and the types of the arguments suggest you're missing the first argument, then that's an opportunity for a much more specific error message. But before we even get to that stage, I would prefer that "." isn't the syntax for both types of call.
- lolinder 2y ago
  Agreed on both counts. We give C++ a lot of flack for verbose syntax, but separating scope resolution (::) from member access (.) is something that it got right, not a place to cut. They're semantically similar, but not the same, which is actually exactly the place where you should distinguish syntax. Using parentheses for both expression grouping and function calls doesn't hurt readability much, but using them for both function calls and array access would. This falls more in the latter category.
pjc50 2y ago
Yuck. The type itself should be a different type from instances of the type, and therefore that error should be "function not found". For the first one, constructors should generally do required init, although there are circumstances where that's very hard. Hence the builder pattern.
- disattention 2y ago
  This is a common pattern in zig and compliments comptime well. It's not supposed to be the constructor for the ArrayList, it's more like a C++ template in that you're constructing a type that then needs to be initialized. There isn't templating syntax in zig though, since you just write compile time code in zig directly (which is really nice). Also, the type is different and ZLS will insert the hint if enabled.
danvk 2y ago
Yes, the error is much clearer when you realize where the mistake is :) There's an interesting point here, though: while comptime lets Zig unify function calls and generic type instantiation, this also creates the possibility of confusing the two and getting confusing error messages.

Dylan16807 2y ago

If the type is `type`, and you're missing one argument, and the types of the arguments suggest you're missing the first argument, then that's an opportunity for a much more specific error message. But before we even get to that stage, I would prefer that "." isn't the syntax for both types of call.

lolinder 2y ago
Agreed on both counts. We give C++ a lot of flack for verbose syntax, but separating scope resolution (::) from member access (.) is something that it got right, not a place to cut. They're semantically similar, but not the same, which is actually exactly the place where you should distinguish syntax. Using parentheses for both expression grouping and function calls doesn't hurt readability much, but using them for both function calls and array access would. This falls more in the latter category.

pjc50 2y ago

Yuck. The type itself should be a different type from instances of the type, and therefore that error should be "function not found". For the first one, constructors should generally do required init, although there are circumstances where that's very hard. Hence the builder pattern.

disattention 2y ago
This is a common pattern in zig and compliments comptime well. It's not supposed to be the constructor for the ArrayList, it's more like a C++ template in that you're constructing a type that then needs to be initialized. There isn't templating syntax in zig though, since you just write compile time code in zig directly (which is really nice). Also, the type is different and ZLS will insert the hint if enabled.

danvk 2y ago

Yes, the error is much clearer when you realize where the mistake is :) There's an interesting point here, though: while comptime lets Zig unify function calls and generic type instantiation, this also creates the possibility of confusing the two and getting confusing error messages.