Earlier quoted context omitted.
Ah, but are those changes in the training data yet?
Probably not, but if this is all AI slop then why bother to read it? There's real documentation (and/or just code). Use it
there's no question of if here...
Zig by Example
51–60 of 109 posts
Re: Zig by Example
#52Encapsulating arguments inside .{} seems superfluous and noisy. I'm sure this can be rationalized in some way, to either simplify parsing or solve some rare ambiguity, but I just don't see it. I know this is a minor thing and can be considered as nitpicky, and I expect some friction with syntax when learning a new language, but I just can't stand things I see as gratuitous. Same with the forced use of _ = foo(.{}); t…
> Encapsulating arguments inside .{} seems superfluous and noisy.
You don't do this? This is only for varargs or optionals.
.{} is just a shorthand for Type{} (struct constructor) plus, "hey compiler, you figure out the type". So if anything it's LESS noisy than the alternative, and more forward-compatible if you change a type name for example.
Re: Zig by Example
#53Encapsulating arguments inside .{} seems superfluous and noisy. I'm sure this can be rationalized in some way, to either simplify parsing or solve some rare ambiguity, but I just don't see it. I know this is a minor thing and can be considered as nitpicky, and I expect some friction with syntax when learning a new language, but I just can't stand things I see as gratuitous. Same with the forced use of _ = foo(.{}); t…
In Zig, function arguments are not wrapped in `.{}`. `.{}` is the syntax for creating a struct or a tuple. This is used as a pattern for allowing optional arguments (options struct) and variadic functions (tuple). Explicitly discarding return values is a thing many modern programming languages force you to do.
I know, and I don't see unused return values as an error, it should be a warning at best.
And the compiler should be just a bit smarter to avoid the .{} thing when it is not strictly necessary.
Re: Zig by Example
#54Looking for a resource (MCP, CLI, Skill, ...) that would improve Zig support in LLMs. Currently, doing something with Zig as a target language would spend many more tokens and produce subpar results.
Wrapping this [1] in a skill will help a lot:
Also add this [2] and `zig fmt` to your buid.zig.
[1]: https://github.com/rockorager/zigdoc [2]: https://github.com/rockorager/ziglint
Re: Zig by Example
#55I just looked this up yesterday so sharing some more up-to-date resources for those interested in Zig: - Learning Zig by Karl Seguin: https://www.openmymind.net/learning_zig/ - https://zig.guide/ - Free project-based online book Introduction to Zig by Pedro Park: https://pedropark99.github.io/zig-book . - Ziglings, almost working programs you need to fix: https://codeberg.org/ziglings/exercises
"More up-to-date" meaning more sources that are also up to date like the OP, or meaning that the OP is not up to date? Silly English language!
Zig by Example seems to target Zig 0.14 at the moment. The links I posted should hopefully target version 0.15+
Re: Zig by Example
#56Is Zig just a trend, or will it become a solidly established language? After all, learning something is an investment of time. With Zig, it doesn't seem to have the same kind of industry pressure as Rust. There's talk in open source circles about AI-related issues, and on Hacker News people say good things about Zig. The allocator concept looks great. But there's also a possibility that it won't become mainstream, li…
Unless you’re actively promoting one of the languages for financial gain, you have nothing to lose by delaying commitment to one, both, or either. If any of them have lasting value, they will be as easy to pick up in the future as they are now. Nobody cares about the old Java or .NET versions where both suffered from limited implementations of generics and other things, and nobody is a better programmer for having us…
Hadn't thought of that and I think you're right.
Having been exposed to Java But there are still many remnants (like null refs, despite Option) that are easiest understood by tracing back Java's historical roots.
Re: Zig by Example
#57Is Zig just a trend, or will it become a solidly established language? After all, learning something is an investment of time. With Zig, it doesn't seem to have the same kind of industry pressure as Rust. There's talk in open source circles about AI-related issues, and on Hacker News people say good things about Zig. The allocator concept looks great. But there's also a possibility that it won't become mainstream, li…
[deleted]
Re: Zig by Example
#58Earlier quoted context omitted.
In Zig, function arguments are not wrapped in `.{}`. `.{}` is the syntax for creating a struct or a tuple. This is used as a pattern for allowing optional arguments (options struct) and variadic functions (tuple). Explicitly discarding return values is a thing many modern programming languages force you to do.
I know, and I don't see unused return values as an error, it should be a warning at best. And the compiler should be just a bit smarter to avoid the .{} thing when it is not strictly necessary.
> And the compiler should be just a bit smarter to avoid the .{} thing when it is not strictly necessary.
What's your plan for this? Rebuilding the C varargs mess from first principles?
Re: Zig by Example
#59Encapsulating arguments inside .{} seems superfluous and noisy. I'm sure this can be rationalized in some way, to either simplify parsing or solve some rare ambiguity, but I just don't see it. I know this is a minor thing and can be considered as nitpicky, and I expect some friction with syntax when learning a new language, but I just can't stand things I see as gratuitous. Same with the forced use of _ = foo(.{}); t…
I see it this way, the full signature for defining a variable is:
var foo: Foo = Foo{};
var foo = Foo{};
var foo: Foo = .{};
So when you see .{} as an argument, it is inferring the type from the function signature. It happens to be empty only because it's using default values (or is a tuple with 0 items).
Edit: fixed the extra dots.
Re: Zig by Example
#60Encapsulating arguments inside .{} seems superfluous and noisy. I'm sure this can be rationalized in some way, to either simplify parsing or solve some rare ambiguity, but I just don't see it. I know this is a minor thing and can be considered as nitpicky, and I expect some friction with syntax when learning a new language, but I just can't stand things I see as gratuitous. Same with the forced use of _ = foo(.{}); t…
I see it this way, the full signature for defining a variable is: var foo: Foo = Foo{}; There's two ways to shorten it: var foo = Foo{}; var foo: Foo = .{}; It can infer the type of the var from the right hand side; or the type of the right side from the type of the var. So when you see .{} as an argument, it is inferring the type from the function signature. It happens to be empty only because it's using default val…
that's not quite right.
1) It's var foo = Foo{...}; (no intervening dot)
2) I think parent commenter is referring to function call use case call_my_func(.{...})