<daurnimator>
hryx: welcome back. you've been missing :)
<hryx>
:D
<daurnimator>
also, merry christmas everyone :)
<fengb>
Merry Christmas!
<leeward>
gonz_: Zig is so similar to so many other languages that people will definitely have years of believing their style is the best.
<leeward>
Syntactically, at least.
<gonz_>
It's different enough to warrant acceptance of how other people do things, IMO.
<gonz_>
I think you'd have to be a pretty odd person to push your particular C style or whatever when doing zig and having a fit about the chosen auto-formatting.
<gonz_>
I think most normal people tend to reset their expectations when trying out something new.
<leeward>
Curly braces surround blocks, indentation is used to indicate nesting, lines of code have to fit on the screen, parentheses surround function argument lists. These are common to most languages with any relationship to C. Telling someone who's been using one style for 30 years that it's time to relearn because some of the language semantics changed is a hard sell. I'm not saying it's the wrong thing to do, but it's not a whole new contex
<leeward>
t with all new conventions.
<gonz_>
It's not really much about the commonalities syntactically to other languages. Zig looks like so many languages that it barely looks meaningfully like any of them, at this point.
doublex_ has quit [Read error: Connection reset by peer]
<gonz_>
What matters in the end is that there is a new community, there is currently one meaningful codebase written in the language, overwhelmingly in that one style.
doublex_ has joined #zig
<gonz_>
It might be hard for someone's ego to hear that it doesn't matter what shape their code has been previously, but I hope that people would see how pointless it is to pretend that you're that special snowflake with your own style all the time.
<leeward>
If you think it's about ego, I think we're having the wrong conversation.
<gonz_>
I think it's inherently about ego, yes. If someone has a hard time accepting a community's formatting there's zero chance it's anything but ego driving that.
<leeward>
Yeah, that's just not true.
<gonz_>
Let's agree to disagree.
<leeward>
That's why I'm not supporting my position.
frmdstryr has quit [Ping timeout: 265 seconds]
mahmudov has quit [Ping timeout: 268 seconds]
<gonz_>
To clarify, I'm talking mainly about pushing ones own style as some kind of alternative when entering an eco system. There are 2+ million lines of zig in the `zig` repo, and for someone, even with many more lines of C under their belt to put their judgment above much more experienced users would be odd to say the least.
<gonz_>
Whatever people do in their private repos or in their own corner of the Internet isn't important and they should probably do whatever they want.
<gonz_>
Over 200k lines, sorry.
<gonz_>
Point being, there are users who have written more code in this particular language, currently maintaining its only remotely significant code base, there's no amount of previous experience that matters in contrast to that in terms of these superficial things like style.
tgschultz has quit [Ping timeout: 258 seconds]
tgschultz has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 268 seconds]
dddddd has quit [Remote host closed the connection]
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
aperezdc has joined #zig
_whitelogger has joined #zig
lygaret has joined #zig
_whitelogger has joined #zig
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
<shachaf>
Does std.json not support indicating EOF? E.g. parse("123") is an error whereas parse("123 ") succeeds.
<shachaf>
This is only relevant for numbers, where the end of the number is marked by EOF rather than by something in the string itself.
_whitelogger has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<Snektron>
I think there is only allowed to be one json root element, maybe its failing with that?
lygaret has quit [Quit: Leaving.]
<shachaf>
Yes, but the root element is allowed to be a number (and it recognizes it when it's terminated by whitespace).
return0e_ has quit [Ping timeout: 240 seconds]
return0e has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 268 seconds]
<Snektron>
Seems like a bug in the implementation to me
_whitelogger has joined #zig
_whitelogger has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
dddddd has joined #zig
orca84 has joined #zig
orca84 has quit [Client Quit]
orca84 has joined #zig
orca84 has quit [Client Quit]
<gonz_>
Does anyone have a solution for the compiler error: "Duplicate integer as switch case"?
<gonz_>
It seems to arise because I'm printing a struct that happens to have a C enum inside of it that I guess has duplicate values or whatever.
<gonz_>
To clarify, I mean: "broken LLVM module found: Duplicate integer as switch case ..."
_whitelogger has joined #zig
<Snektron>
You could override the .format option to not (or manually) print that struct