You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Value assignment has the following syntax: (const|var) identifier[: type] = value.
const indicates that identifier is a constant that stores an immutable value.
var indicates that identifier is a variable that stores a mutable value.
: type is a type annotation for identifier, and may be omitted if the data type of value can be inferred.
constconstant: i32=5; // signed 32-bit constantvarvariable: u32=5000; // unsigned 32-bit variable// @as performs an explicit type coercionconstinferred_constant=@as(i32, 5);
varinferred_variable=@as(u32, 5000);
I think it would be better to elaborate on how type inference works over here by showing all of the methods available to do so. In my limited knowledge of Zig, these are the three methods I know of:
// 1. Explicit coercion (as shown above in your example):varinferred_variable=@as(u32, 5000);
// 2. Inference from existing variablesvara: i32=1;
varb=a+1; // Inferred as i32// 3. Using the comptime directive to force a comptime_intcomptimevara=1;
I think showing the second method out of the three would be the best display of the use of inferred assignment in Zig, and thus should be shown first.
This is also I think a good place to show to the reader early how compile time evaluation works and what comptime_int is in Zig. A short description of both components and a link to the later section about comptime would be sufficient, considering that this tutorial is directed toward people already familiar with a programming language.
The text was updated successfully, but these errors were encountered:
1 and 2 are equivalent; from the perspective of assignment + type inference, they're the same
3 is more complicated, in that var acts as comptime var when in a comptime block
I'm working on restructuring some things at the moment, and I agree a good idea to introduce comptime sooner, but I don't think this is a good solution.
1 and 2 are equivalent; from the perspective of assignment + type inference, they're the same
I agree that they achieve the same thing here, however my intent was to show the reader that it is possible to write such idioms as presented in method 2. Method 2 may not be as obvious to the reader if only method 1 is presented to them. Also, I don't think a user is likely to use explicit coercion everytime inferrred assignment is used, thus rendering method 1 an illustration of a valid use, but a bit useless. Illustration both method 1 and 2 would be a good idea imo.
3 is more complicated, in that var acts as comptime var when in a comptime block
I'm working on restructuring some things at the moment, and I agree a good idea to introduce comptime sooner, but I don't think this is a good solution.
Yes, I agree that a better approach than what I suggested for this would be a more suitable solution.
In Chapter 1, Section 1:
I think it would be better to elaborate on how type inference works over here by showing all of the methods available to do so. In my limited knowledge of Zig, these are the three methods I know of:
I think showing the second method out of the three would be the best display of the use of inferred assignment in Zig, and thus should be shown first.
This is also I think a good place to show to the reader early how compile time evaluation works and what
comptime_int
is in Zig. A short description of both components and a link to the later section aboutcomptime
would be sufficient, considering that this tutorial is directed toward people already familiar with a programming language.The text was updated successfully, but these errors were encountered: