4 ms·

Encapsulating arguments inside .{} seems superfluous and noisy. I'm sure this can be rationalized in some way, to either simplify parsing or solve some rare am

Encapsulating 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(.{}); to avoid compiling errors...

brodo 4mo ago
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.
- stephc_int13 4mo ago
  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.
  - dnautics 4mo ago
    > 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?
dnautics 4mo ago
> Encapsulating arguments inside .{} seems superfluous and noisy. You don't do this? This is only for varargs or optionals. .{<stuff>} is just a shorthand for Type{<stuff>} (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.
hiccuphippo 4mo ago
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 values (or is a tuple with 0 items). Edit: fixed the extra dots.
- dnautics 4mo ago
  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(.{...})
  - hiccuphippo 4mo ago
    1) Ah yes, just typing from memory. Point still stands. 2) Adressed in the last paragraph.
    - dnautics 4mo ago
      Point being, these two things aren't different (variable assignment and function calls); IIUC they go through the same analysis pathway, result location semantics. https://ziglang.org/documentation/master/#Result-Location-Semantics https://ziglang.org/documentation/master/#Result-Location-Se... It's a little bit weird, since the types flow in the reverse direction than you would expect.

brodo 4mo ago

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.

stephc_int13 4mo ago
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.
- dnautics 4mo ago
  > 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?

dnautics 4mo ago

> Encapsulating arguments inside .{} seems superfluous and noisy. You don't do this? This is only for varargs or optionals. .{<stuff>} is just a shorthand for Type{<stuff>} (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.

hiccuphippo 4mo ago

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 values (or is a tuple with 0 items). Edit: fixed the extra dots.

dnautics 4mo ago
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(.{...})
- hiccuphippo 4mo ago
  1) Ah yes, just typing from memory. Point still stands. 2) Adressed in the last paragraph.
  - dnautics 4mo ago
    Point being, these two things aren't different (variable assignment and function calls); IIUC they go through the same analysis pathway, result location semantics. https://ziglang.org/documentation/master/#Result-Location-Semantics https://ziglang.org/documentation/master/#Result-Location-Se... It's a little bit weird, since the types flow in the reverse direction than you would expect.