6 ms·

> For loops are a bit strange too - you write for (items) |item| {} >, which means you specify the container before the per-element variable. Mentally I thi

by e12e 5y ago

> For loops are a bit strange too - you write for (items) |item| {} >, which means you specify the container before the per-element variable. Mentally I think of for as for something in many_things {} and so in Zig I constantly had to write it wrong and then rewrite. That does feel like the syntax is missing an "each" or a "with", as in "for each somethings as some do" or "with each somethings as some" - or in a similar terse/compact syntax: each (items) |item| {} I'm surprised there's no mention about (lack of) string type - considering the domain (advent of code). I've not found the time to actually work on aoc this year, but I also had a brief look at starting with Zig - and quickly met a bit of a wall between the terse documententation on allocator, and the apparent lack of standard library support for working with strings. I think the documentation will improve as the language stabilizes and there's likely to be more tutorials that work with text (both trivial like sirt/cat/tac in zig, and more useful like http or dns client and servers etc).

kzrdude 5y ago
In "The Good" section, the author says there are only while loops and no for.. but apparently there is a for, now I'm unsure what it means. Is `for` a function?
- firethief 5y ago
  `for` is a foreach. If you want to increment a number through a range like a typical C `for`, you have to use a `while` loop. I don't really see the draw.
  - dnautics 5y ago
    man if I were andrew I'd just rename for to "foreach", because this is a huge complaint and source of confusion.
    - kzrdude 5y ago
      Seems fine to me. Rust has a "foreach" which is named for, working ok. Of course Rust has ranges as iterators, so it's not necessarily noticed that "there is no numerical for" but it works.
      - masklinn 5y ago
        > Rust has a "foreach" which is named for, working ok. Also ruby / python. Don't see the point of a C-style for loop in a modern language, reusing the keyword is perfectly sensible (even more so as many which have both use the same keyword). C# actively weirds me out every time from having both for and foreach, complete waste of brainspace.
    - anonymoushn 5y ago
      It seems fine to just delete it if it's only ever going to work on slices and arrays
winter_squirrel 5y ago
It saddens me that a proper string type is a hill the zig folks are willing to die on. The language would have _felt_ a lot better if they would have (at least) just copied what rust did with strings. I understand the argument that in most situations a byte array might be what you actually want, but in practice it feels very dirty to be passing byte arrays around instead of expressing the underlying meaning of that byte array as a type (in this instance a String type). Having a string type also makes any standard library functions on strings infinitely easier to discover.
eirojhupp 5y ago
for strings, these might be good (haven't tried them yet): https://github.com/jecolon/zigstr https://github.com/jecolon/zigstr https://github.com/jecolon/ziglyph https://github.com/jecolon/ziglyph
llimllib 5y ago
I found the standard library's support for strings was plenty fine, doing AoC problems in zig tests it out thoroughly. Tokenize[1], split[2] and trim[3] were the most common ones I used. Was there something in particular you were looking for and didn't find? [1]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L1548 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [2]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L1642 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [3]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L945 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... * After I read my own comment, I'd note that AoC tests out string manipulation pretty thoroughly but things like unicode handling not at all, so []const u8 as a string may be more annoying in the real world than in AoC answers and I haven't used zig's unicode facilities at all
- tialaramex 5y ago
  In AoC it's completely fine to conflate a character and a byte. Neither your daily input nor the provided tests will have anything beyond ASCII. Which is fine for AoC, good choice, but it means the language needn't get this right, or even provide any help to programmers who need to get it right, in a similar way to how "big" numeric answers in AoC will fit in a 64-bit signed integer, never testing whether your chosen language can do better if the need arises.
- shakow 5y ago
  > Was there something in particular you were looking for and didn't find? Unicode handling. Treating a string as a byte array is all fine and dandy if you're only processing english latin alphabet data, but it's a PITA as soon as you start using e.g. extended characters (math symbols, fancy quotes, ...) other languages, or emojis.
  - llimllib 5y ago
    There is the `std.unicode` module[1] which provides standard unicode functions (encode, decode, length, iteration over code points), so I don't think it's fair to say that the language's library lacks strings in any real sense. I will re-emphasize that I've not used it, so I cannot speak for its quality. [1]: https://github.com/ziglang/zig/blob/master/lib/std/unicode.zig https://github.com/ziglang/zig/blob/master/lib/std/unicode.z...
chubot 5y ago
I thought this syntax was weird too, but one cool thing is that you can ask for the index too for (items) |i, item| { } I guess Go does something similar, but it's a little weirder IMO because it has maps, while Zig doesn't. I suppose it could have been for i, item in items { } But I guess coming from Python that feels like tuple unpacking, which I don't think Zig has, but could make sense?
- ReactiveJelly 5y ago
  Lua also has for i, v in ipairs (t) do -- i is the index, v is the value end Not getting the index in C++ easily was very frustrating. Often in C++ I fall back on C-style for-loops just because the functional stuff is hard to remember. In Rust it doesn't give you the index by default, but the `enumerate` adapter adds an index anywhere in a functional pipeline.

by e12e 5y ago

kzrdude 5y ago

In "The Good" section, the author says there are only while loops and no for.. but apparently there is a for, now I'm unsure what it means. Is `for` a function?

firethief 5y ago
`for` is a foreach. If you want to increment a number through a range like a typical C `for`, you have to use a `while` loop. I don't really see the draw.
- dnautics 5y ago
  man if I were andrew I'd just rename for to "foreach", because this is a huge complaint and source of confusion.
  - kzrdude 5y ago
    Seems fine to me. Rust has a "foreach" which is named for, working ok. Of course Rust has ranges as iterators, so it's not necessarily noticed that "there is no numerical for" but it works.
    - masklinn 5y ago
      > Rust has a "foreach" which is named for, working ok. Also ruby / python. Don't see the point of a C-style for loop in a modern language, reusing the keyword is perfectly sensible (even more so as many which have both use the same keyword). C# actively weirds me out every time from having both for and foreach, complete waste of brainspace.
  - anonymoushn 5y ago
    It seems fine to just delete it if it's only ever going to work on slices and arrays

winter_squirrel 5y ago

It saddens me that a proper string type is a hill the zig folks are willing to die on. The language would have _felt_ a lot better if they would have (at least) just copied what rust did with strings. I understand the argument that in most situations a byte array might be what you actually want, but in practice it feels very dirty to be passing byte arrays around instead of expressing the underlying meaning of that byte array as a type (in this instance a String type). Having a string type also makes any standard library functions on strings infinitely easier to discover.

eirojhupp 5y ago

for strings, these might be good (haven't tried them yet): https://github.com/jecolon/zigstr https://github.com/jecolon/zigstr https://github.com/jecolon/ziglyph https://github.com/jecolon/ziglyph

llimllib 5y ago

I found the standard library's support for strings was plenty fine, doing AoC problems in zig tests it out thoroughly. Tokenize[1], split[2] and trim[3] were the most common ones I used. Was there something in particular you were looking for and didn't find? [1]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L1548 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [2]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L1642 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... [3]: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L945 https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L... * After I read my own comment, I'd note that AoC tests out string manipulation pretty thoroughly but things like unicode handling not at all, so []const u8 as a string may be more annoying in the real world than in AoC answers and I haven't used zig's unicode facilities at all

tialaramex 5y ago
In AoC it's completely fine to conflate a character and a byte. Neither your daily input nor the provided tests will have anything beyond ASCII. Which is fine for AoC, good choice, but it means the language needn't get this right, or even provide any help to programmers who need to get it right, in a similar way to how "big" numeric answers in AoC will fit in a 64-bit signed integer, never testing whether your chosen language can do better if the need arises.
shakow 5y ago
> Was there something in particular you were looking for and didn't find? Unicode handling. Treating a string as a byte array is all fine and dandy if you're only processing english latin alphabet data, but it's a PITA as soon as you start using e.g. extended characters (math symbols, fancy quotes, ...) other languages, or emojis.
- llimllib 5y ago
  There is the `std.unicode` module[1] which provides standard unicode functions (encode, decode, length, iteration over code points), so I don't think it's fair to say that the language's library lacks strings in any real sense. I will re-emphasize that I've not used it, so I cannot speak for its quality. [1]: https://github.com/ziglang/zig/blob/master/lib/std/unicode.zig https://github.com/ziglang/zig/blob/master/lib/std/unicode.z...

chubot 5y ago

I thought this syntax was weird too, but one cool thing is that you can ask for the index too for (items) |i, item| { } I guess Go does something similar, but it's a little weirder IMO because it has maps, while Zig doesn't. I suppose it could have been for i, item in items { } But I guess coming from Python that feels like tuple unpacking, which I don't think Zig has, but could make sense?

ReactiveJelly 5y ago
Lua also has for i, v in ipairs (t) do -- i is the index, v is the value end Not getting the index in C++ easily was very frustrating. Often in C++ I fall back on C-style for-loops just because the functional stuff is hard to remember. In Rust it doesn't give you the index by default, but the `enumerate` adapter adds an index anywhere in a functional pipeline.