Iād like it if the language supported something like this:
for (0..) |byte: u8| {
// ....
}
There are a few possible ways to phrase this, two more: for(@as(u8, 0..))
, for(@as(u8, 0)..)
, I just chose my favorite from the associated proposal. The other two turn @as
into āmagicā, which, a builtin can be magic, but that tendency should be resisted. The above syntax is consistent with specifying the type of a numeric literal to cast it down from comptime_int
.
That issue was closed, this was the main part of the reasoning given (quote is Andrew Kelley):
If you tried to implement your proposal, you would see the problems with it.
That strikes me as a good reason for Andrew / the Zig Foundation to not work on the issue, but not so great a reason to close it. Thereās a difference between āthis is not good for Zigā and āthis is harder than you think, and the benefits are not worth the time I would have to devote to itā. Either of these is a fully legitimate reason for the core team not to devote time to the feature, but if the latter reasoning is in fact primary, maybe someone else would be willing to tackle the implementation complexity without making it the teamās problem.
Thereās also a question of where to stop, but āfor ranges are increment only, integer only, and always increment by one, automaticallyā is defensible. Anything else should be using a while
loop, whether with a postcondition or an iterator. That keeps the semantics of for
loops clean, and consistent with their use to iterate over slices/arrays/Vectors, but also opens up range types which arenāt usize
, which is clearly valuable (or people wouldnāt keep asking this question).
It seems to have been closed as part of a general cleanup (see the rest of the comment). That kind of thing happens. I do hope room is left to reconsider the question at some later time.