3 ms·

Because we've said x is a constant we're obliged to specify its type. For variables we're allowed to use inference and in most cases the type can be correctly i

Because we've said x is a constant we're obliged to specify its type. For variables we're allowed to use inference and in most cases the type can be correctly inferred, but for constants or function signatures inference is deliberately prohibited. const x: Rect = .... [Note that in Zig what you've written isn't a constant, Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant]

flohofwoe 1y ago
> Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant I think it's a bit more complicated than that: AFAIK Zig consts without explicit type may be comptime_int or comptime_float, and those don't exist at runtime. Only consts with an explicit type annotation are 'runtime consts'. Also see: https://www.godbolt.org/z/esTr463bT https://www.godbolt.org/z/esTr463bT ...still, I think Rust should allow to infer the type at least inside struct initialization, it would make designated init code like this a lot less noisy (Zig would suffer from the same problem if it hadn't the .{} syntax): https://github.com/floooh/sokol-rust/blob/main/examples/texcube/texcube.rs#L125-L147 https://github.com/floooh/sokol-rust/blob/main/examples/texc... ...C99 is still the 'benchmark' when it comes to struct initialization: https://github.com/floooh/sokol-samples/blob/29d5e9f4a56ae1884c4ffa7178b1af739d827d07/sapp/texcube-sapp.c#L119-L136 https://github.com/floooh/sokol-samples/blob/29d5e9f4a56ae18...
- tialaramex 1y ago
  Surely Rust can infer the type in your example? It just doesn't provide Zig's syntax to use the inferred type to manually initialize. If you wrote some_fn() here where some_fn's return type was genericised, Rust would ask for the appropriately typed some_fn not say it doesn't know the type.
  - flohofwoe 1y ago
    > Surely Rust can infer the type in your example? Well in Rust code like this: pass_action.colors[0] = sg::ColorAttachmentAction { load_action: sg::LoadAction::Clear, clear_value: sg::Color { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...I cannot write: pass_action.colors[0] = { load_action: sg::LoadAction::Clear, clear_value: { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...even though the Rust compiler has all the type information it needs (from the 'left-hand-side'). For comparison, in Zig it would look like this: pass_action.colors[0] = .{ .load_action = .Clear, .clear_value = .{ .r=0.25, .g=0.5, .b=0.75, .a=1.0 }, }; ...Zig is still only halfway there compared to C99 (e.g. Zig doesn't allow designator chaining and is much less flexible for initializing nested arrays - in those areas it's closer to Rust than C).
    - tialaramex 1y ago
      Right but your call to Default::default() gives the game away that we do have inference. Default::default() is generic, if we didn't have inference we'd need to tell it which of the enormous number of implementations of that trait it should call. Would you take syntax like clear_value: _ { r: 0.25, g: 0.5, g: 0.75, a: 1.0 } ?? Then we're saying that we know we need to pick a type here but the type can be inferred where our underscore was, just like when we let words: Vec<_> = "A sentence broken by spaces".split_whitespace().collect();

flohofwoe 1y ago

> Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant I think it's a bit more complicated than that: AFAIK Zig consts without explicit type may be comptime_int or comptime_float, and those don't exist at runtime. Only consts with an explicit type annotation are 'runtime consts'. Also see: https://www.godbolt.org/z/esTr463bT https://www.godbolt.org/z/esTr463bT ...still, I think Rust should allow to infer the type at least inside struct initialization, it would make designated init code like this a lot less noisy (Zig would suffer from the same problem if it hadn't the .{} syntax): https://github.com/floooh/sokol-rust/blob/main/examples/texcube/texcube.rs#L125-L147 https://github.com/floooh/sokol-rust/blob/main/examples/texc... ...C99 is still the 'benchmark' when it comes to struct initialization: https://github.com/floooh/sokol-samples/blob/29d5e9f4a56ae1884c4ffa7178b1af739d827d07/sapp/texcube-sapp.c#L119-L136 https://github.com/floooh/sokol-samples/blob/29d5e9f4a56ae18...

tialaramex 1y ago
Surely Rust can infer the type in your example? It just doesn't provide Zig's syntax to use the inferred type to manually initialize. If you wrote some_fn() here where some_fn's return type was genericised, Rust would ask for the appropriately typed some_fn not say it doesn't know the type.
- flohofwoe 1y ago
  > Surely Rust can infer the type in your example? Well in Rust code like this: pass_action.colors[0] = sg::ColorAttachmentAction { load_action: sg::LoadAction::Clear, clear_value: sg::Color { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...I cannot write: pass_action.colors[0] = { load_action: sg::LoadAction::Clear, clear_value: { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...even though the Rust compiler has all the type information it needs (from the 'left-hand-side'). For comparison, in Zig it would look like this: pass_action.colors[0] = .{ .load_action = .Clear, .clear_value = .{ .r=0.25, .g=0.5, .b=0.75, .a=1.0 }, }; ...Zig is still only halfway there compared to C99 (e.g. Zig doesn't allow designator chaining and is much less flexible for initializing nested arrays - in those areas it's closer to Rust than C).
  - tialaramex 1y ago
    Right but your call to Default::default() gives the game away that we do have inference. Default::default() is generic, if we didn't have inference we'd need to tell it which of the enormous number of implementations of that trait it should call. Would you take syntax like clear_value: _ { r: 0.25, g: 0.5, g: 0.75, a: 1.0 } ?? Then we're saying that we know we need to pick a type here but the type can be inferred where our underscore was, just like when we let words: Vec<_> = "A sentence broken by spaces".split_whitespace().collect();