ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
ur5us has quit [Ping timeout: 264 seconds]
jukan has quit [Ping timeout: 264 seconds]
jukan has joined #zig
jukan has quit [Ping timeout: 265 seconds]
procnto has quit [Ping timeout: 244 seconds]
nikki93 has quit [Read error: Connection reset by peer]
sjd has quit [Ping timeout: 260 seconds]
nikita` has quit [Ping timeout: 264 seconds]
kushalp has quit [Ping timeout: 244 seconds]
kwilczynski has quit [Ping timeout: 272 seconds]
nikita` has joined #zig
sharpobject has quit [Ping timeout: 260 seconds]
kwilczynski has joined #zig
rtpg has quit [Ping timeout: 264 seconds]
nikki93 has joined #zig
procnto has joined #zig
tracernz has quit [Ping timeout: 244 seconds]
r0bby_ has joined #zig
r0bby has quit [Ping timeout: 272 seconds]
r0bby_ is now known as r0bby
gonz_ has quit [Ping timeout: 260 seconds]
hnOsmium0001 has quit [Ping timeout: 265 seconds]
rtpg has joined #zig
tracernz has joined #zig
kushalp has joined #zig
gonz_ has joined #zig
hnOsmium0001 has joined #zig
WilhelmVonWeiner has joined #zig
ur5us has joined #zig
WilhelmVonWeiner has quit [Quit: leaving]
rowbee has quit [Remote host closed the connection]
rowbee has joined #zig
xackus has joined #zig
jukan has joined #zig
xackus has quit [Ping timeout: 260 seconds]
jukan has quit [Ping timeout: 264 seconds]
<pixelherodev> Even I intend to support zig cc :P
<pixelherodev> (just not with llvm :)
jukan has joined #zig
jukan has quit [Ping timeout: 265 seconds]
jukan has joined #zig
gazler has quit [Read error: Connection reset by peer]
sjd has joined #zig
decentpenguin has quit [Ping timeout: 256 seconds]
squeek502 has joined #zig
v0idify has quit [Ping timeout: 268 seconds]
decentpenguin has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
decentpenguin has quit [Ping timeout: 260 seconds]
r0bby has quit [Ping timeout: 265 seconds]
r0bby has joined #zig
squeek502 has quit [Ping timeout: 240 seconds]
squeek502 has joined #zig
jukan has quit [Ping timeout: 240 seconds]
<companion_cube> Will it be part of the spec then?
cole-h has quit [Ping timeout: 246 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> the language spec governs the language, not the toolchain
jukan has joined #zig
_whitelogger has joined #zig
decentpenguin has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 256 seconds]
sord937 has joined #zig
gazler has joined #zig
gazler has quit [Client Quit]
<rtpg> Is there a rule of thumb regarding @cInclude @cImport groupings? is it like "if these are referencing stuff within each other they need to be included together"?
decentpenguin has quit [Ping timeout: 265 seconds]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
jukan has joined #zig
ur5us has joined #zig
jukan has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 260 seconds]
leon-p has joined #zig
mmkarakaya has joined #zig
jokoon has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 260 seconds]
earl has quit [Ping timeout: 272 seconds]
iceball has joined #zig
Wolf480pl has quit [Quit: ZNC disconnected]
Wolf480pl has joined #zig
bkleiner has quit [Quit: bye]
xentec has quit [Remote host closed the connection]
mokafolio has quit [Ping timeout: 246 seconds]
bkleiner has joined #zig
bsrd has quit [Ping timeout: 260 seconds]
sjums has quit [Ping timeout: 260 seconds]
xentec has joined #zig
sjums has joined #zig
pixelherodev has quit [Changing host]
pixelherodev has joined #zig
M-ou-se has quit [Ping timeout: 260 seconds]
mokafolio has joined #zig
M-ou-se has joined #zig
earl has joined #zig
cmrs has quit [Quit: ZNC 1.7.5 - https://znc.in]
jukan has joined #zig
<leon-p> Is there something like Cs getline() in std? something that puts a single line from stdin into an allocated buffer. I only found functions that have a max_length arguement, but my use case is for arbitrarily long lines, so those are probably not what I want.
<g-w1> make max_len std.math.maxInt(usize)
jukan has quit [Ping timeout: 260 seconds]
<leon-p> That is what I have done currently to get the project working. But isn't setting max_length to a very high number, even if it is considerably larger than any realistic input line will ever be, just a hack?
jokoon has quit [Quit: Leaving]
<dutchie> you are going to have trouble trying to store a line longer than std.math.maxInt(usize)
<dutchie> even if you somehow don't run out of memory, indexing is going to get weird, so you'll probably need multiple buffers anyway
<dutchie> it's not a hack, just reflecting the fact that real computers do have actual limits
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
jokoon has joined #zig
<g-w1> im pretty sure the c function would break if it went above the limit, so zig makes it explicit
<leon-p> i see, hadn't considered it from that angle, thanks!
earnestly has joined #zig
Akuli has joined #zig
waleee-cl has joined #zig
donniewest has joined #zig
mmkarakaya has quit [Quit: Ping timeout (120 seconds)]
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
jukan has joined #zig
kbd has joined #zig
Flaminator has joined #zig
nvmd has joined #zig
jokoon has quit [Quit: Leaving]
hnOsmium0001 has joined #zig
dfrey has joined #zig
jukan has quit [Ping timeout: 265 seconds]
<dfrey> Hi. I'm new to Zig, but I'm an experienced C programmer. I'm reading this section (https://ziglang.org/documentation/0.7.1/#Global-Variables) and I'm a bit confused. The S.x variable is behaving like a function static variable in C, but I don't really understand why. So why is the lifetime of S longer than a single execution of the foo function?
<ifreund> indeed, S is a type
<ifreund> and x is a global variable in the namespace of S
<ifreund> if you instantiate the type S and make x into a field, it would be local to the function and return the same result every time: https://0x0.st/--u5.txt
<ifreund> dfrey: here's a possibly better explanation, the variable S is indeed local to that function, but the type value it holds is gloabal as all types ar
<ifreund> *are
<Gliptic> how would I go about getting the type of a struct field, I suppose I could do @TypeOf(@as(Struct, undefined).field) or something silly like that
<dfrey> const S1 = struct { var x: i32; }; const S2 = struct { x: i32; }; So is it correct to say that x is a variable associated with the type for S1 and a variable associated with an instance for S2?
<Gliptic> is there a nicer way
<ifreund> dfrey: well, the second won't compile, you need a comma to make a field: const S2 = struct { x: i32, };
<ifreund> but yes that is correct
<dfrey> thanks
<ifreund> Gliptic: you could do std.meta.fieldInfo(MySruct, .field_name).field_type
<ifreund> that's less hacky but not really more concicse
<Gliptic> right, I forget about std.meta
<g-w1> the first wont compile either since you need an = when declaring variables
<ifreund> right, zig requires you to initialize all variables, even if just to undefined
stilbruch has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
jukan has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
notzmv has joined #zig
a_chou has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
a_chou has quit [Remote host closed the connection]
frett27 has joined #zig
ur5us has joined #zig
kbd has joined #zig
xyproto has quit [Ping timeout: 264 seconds]
sord937 has quit [*.net *.split]
nycex has quit [*.net *.split]
ur5us has quit [Ping timeout: 264 seconds]
xyproto has joined #zig
wilsonk has quit [Ping timeout: 272 seconds]
cole-h has joined #zig
nycex has joined #zig
ur5us has joined #zig
jukan_ has joined #zig
sord937 has joined #zig
jukan has quit [Ping timeout: 260 seconds]
jukan has joined #zig
jukan_ has quit [Ping timeout: 272 seconds]
xackus has joined #zig
v0idify has joined #zig
ur5us_ has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
sord937 has quit [Quit: sord937]
jukan_ has joined #zig
jukan has quit [Ping timeout: 256 seconds]
dputtick has quit [Ping timeout: 260 seconds]
dch has quit [Read error: Connection reset by peer]
nikki93 has quit [Ping timeout: 265 seconds]
dch has joined #zig
kwilczynski has quit [Ping timeout: 272 seconds]
nikki93 has joined #zig
dputtick has joined #zig
kwilczynski has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
notzmv has quit [Ping timeout: 260 seconds]
Akuli has quit [Quit: Leaving]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
zags has joined #zig
<zags> Hey. I know it's prolly too late now, but was adding support for general union types and flow-sensitive typing ever discussed? By flow-sensitive typing, I mean automatic narrowing based on type tests so you don't need additional casts.
<ifreund> I'm not sure I understand what you mean, how is that different from the tagged unions we have today?
<ifreund> oh yeah I've seen that in kotlin before, I'm not much of a fan myself tbh
<zags> How come? It's been a delight to work with imo
<zags> Especially in Ceylon which has proper union types
<ifreund> It makes writing the code less effort but I don't like how implicit it is whlie reading
<zags> It's not implicit
<zags> It just collapses the type check and the cast
<zags> I find it very readable and clear
<ifreund> What I mean is that a line of code at the start of a block affects what is legal in the rest of the block in a somewhat invisible way
<ifreund> if you have a large block, this seems like it could cause readability issues
<ifreund> I haven't used it enough to really speak from a position of authority though
<zags> Yeah well I think it's a great approach
<zags> Less noise, same clarity
<zags> of type (just one type check/cast instead of having them separate)
<ifreund> zig's || capture things handle this just fine for me
<ifreund> And they do combine the type check/cast into one step
<zags> that just unwrapping, not flow sensitive control
<zags> convenient, but orthogonal
<ifreund> what would be an example of a check/cast that needs to separate in zig today?
<zags> Well my original question is about union types :) That's where it becomes useful.
<zags> I don't know Zig well enough to know if the existing constructs are sufficient with that mind, it may very well be.
<zags> Something a lot of languages are picking up so was curious if it was discussed
<ifreund> switching on a tagged union allows you to use || captures on the switch arms
<ifreund> I'm having a lot of trouble seeing what zig would gain from this feature tbh since it always makes potentially unsafe casting explicit
<ifreund> I guess if implemented it would allow leaving off the .? on optionals if you've checked for null
<ifreund> but this seems strictly less readable than the if (foo) |unwrapped| status quo
<zags> Moving right along
donniewest has quit [Ping timeout: 265 seconds]
<daurnimator> huh. where did `zig builtin` go?
<g-w1> zig build-exe --show-builtin iirc
<daurnimator> g-w1: thanks! works. that's not in the --help output
<zags> total zig-noob succinctness question: https://pastebin.com/raw/4FhkBX9g
<Gliptic> slices are confusing me somewhat, how come this works: var str: []const u8 = "test"; const slice: [][]const u8 = &[_][]const u8 { str };
<Gliptic> but not: const slice: [][]const u8 = &[_][]const u8 { @as([]const u8, "test") };
<Gliptic> should it really matter if the slice temporarily was in a variable
<ifreund> zags: you want catch |err| switch (err) { ... };
<ifreund> Gliptic: you're missing a const, this would work; `const slice: []const []const u8 = &[_][]const u8{ "test" };
<Gliptic> you'd think so, but no
<Gliptic> error: expected type '[][]const u8', found '[]const []const u8'
<ifreund> Gliptic: that's an issue with how you are using the slice then...
<ifreund> do you really need the outer one to be mutable?
<Gliptic> hm, ah, the const was missing from the parameter type I pass it to
nvmd has quit [Quit: Later nerds.]
<zags> ifreund: lol, I did try that but got errors and starting trying increasingly complex things. Turns out I had try x catch ..., removing try works like a charm.
<zags> Seems like the compiler could say "did you mean to use catch here?" instead of expected error union type, found 'Mod.SomeStruct()'
<zags> It's not wrong, just some clang-style magical insightful errors would be helpful
<ifreund> oh yeah, the stage 1 compile error messages are pretty bad
<zags> I see
<ifreund> as you might imagine, there's not much motivation to improve them as stage2 is the long term goal
<zags> so stage1 will be nuked long term?
<zags> not sure how it's structured
<ifreund> indeed, stage1 is the C++ implementation that is currently used to build zig
<zags> ohhhh
<ifreund> large parts of the compiler frontend are already self-hosted though
<zags> so it'll be self-hosted
<zags> right
<ifreund> so your zig binary is actually a mix of zig and c++ code
<ifreund> when stage2 codegen is feature complete the C++ implementation can be deleted
<zags> I see, yeah that must be a torn in the eye for zig compiler devs
<ifreund> there's also a lot of design issues in stage1, which is why it's so slow and such a memory hog
<zags> on larger things, the part that emits llvm is slow as well it seems - will that be improved?
<zags> i guess llvm isn't as fast as it used to be
frett27 has quit [Ping timeout: 272 seconds]
<g-w1> stage2 wont depend on llvm
<g-w1> its optional
<zags> Is the plan to reimplement optimizations, or is that where you switch to llvm (for release builds) ?