ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
jfo has quit [Ping timeout: 260 seconds]
zesterer has quit [Quit: zesterer]
zesterer has joined #zig
zesterer has quit [Quit: zesterer]
zesterer has joined #zig
zesterer has quit [Quit: zesterer]
hoppetosse has quit [Ping timeout: 268 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
SimonNa has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
cenomla has quit [Quit: cenomla]
cenomla has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
cenomla has quit [Quit: cenomla]
jfo has joined #zig
jfo has quit [Ping timeout: 276 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
arBmind has joined #zig
dd3 has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
dd3 has quit [Ping timeout: 256 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
arBmind has quit [Quit: Leaving.]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hoppetosse has joined #zig
jfo has quit [Ping timeout: 265 seconds]
jfo has joined #zig
hopppetosse has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
zesterer has joined #zig
jfo has quit [Quit: WeeChat 1.9.1]
hoppetosse has joined #zig
hopppetosse has quit [Ping timeout: 240 seconds]
tjpalmer has joined #zig
<tjpalmer> jfo, thanks for the tips. I guess I thought it was further along than it was, including in llvm.
tjpalmer has quit [Client Quit]
<SimonNa> hi, I gave Zig a try :) I'm in examples/guess_number, 'zig build' fails; only if I move ./main.zig to ./src/main.zig, game compiles and works well
<SimonNa> (Arch 64 bit, I built Zig from github repository)
<SimonNa> I suppose 'zig build' is the correct command still to build, or what would the workflow be?
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has joined #zig
<jfo> SimonNa: I think the standard build template expects main.zig to live in ./src, but that is configurable (when you run `zig build` in a directory without a build.zig file, it writes a template for you.)
<jfo> you can also compile the main directly with `zig build-exe main.zig`, that should work wherever `main.zig` is if it's not referencing relative paths with @import
<SimonNa> ah, yes, it writes build.zig and that then points to nonexistant src/main.zip
<SimonNa> yeah, build-exe works out of the box :)
<jfo> I find this behavior a little confusing too, I would expect the template to be a flag like `zig build --template` and for `zig build` to fail if there is no build.zig
<jfo> :)
<jfo> it's very easy to run build in the wrong directory or something and have a new file
<SimonNa> yes, that sounds easier to understand
<SimonNa> in the impl, on 'zig build' I even got compile errors (with lines in the example), surely it couldn't be that the example had this many errors
<SimonNa> yeah, would have expected a cleaner, shorter error here
<SimonNa> anyway, building Zig in the first place went well, sticking 100 % to the build instructions from the github readme, that was good
<jfo> :+1:
<SimonNa> the compelling features are the non-null and non-error by default, and forced un-nulling/un-error-packing when an API allows returning null/error
<SimonNa> thanks, good idea to report. I'll reply later with the experience from building the example game
<SimonNa> it's easy to look into the generated files and guess a working setup, but better error would indeed be nice
Hejsil has joined #zig
<jfo> hi Hejsil
<Hejsil> Yo
<jfo> SimonNa, please do! that's valuable new user experience testing :)
<SimonNa> hnn :)
davr0s has joined #zig
<Hejsil> jfo, your method issue made me realize the magic of method calls in Zig. It's not a lot, but calling methods is basically syntactic sugar for @typeOf(instance).method(instance)
<Hejsil> Which is a weird behavior, compared to the normal namespace access that . does
<jfo> yes I think the core issue is the overloading (as it were) of dot access
<jfo> I find it strange that I use the same syntax for both "instance" and "static" "methods"
<jfo> sorry for all the quotes but I don't mean to use these terms concretely though they are currently applicable
<jfo> and oh yeah I see what you're saying with @typeOf
<Hejsil> I think, "instance" and "static" makes sense. It's basicly just namespace access
<jfo> yes I just don't want to pin the discussion to that framing, there is a lot of baggage that comes with the terminology
<Hejsil> Ye, you need typeOf to avoid the method magic
<jfo> like you said to avoid public protected etc
<Hejsil> Uuurh, if method syntax changes, then my codebase will break hard
<Hejsil> Again
<Hejsil> Lol
<jfo> the ability to treat a struct body as just another scope is really interesting to me, you can do some funky variable psuedo capture kind of
<jfo> I don't think changing the syntax is necessarily the right idea, I was just trying to make it clearer when something is taking self
<Hejsil> Well, let's see what happens
<jfo> one of the only things I like about javascript is the ability to name anon functions with variable assignment
<jfo> if we had both anon function syntax and default struct init values, that could be a way to make a distinction b/t instance and static method. I haven't fully though this through yet though so I'm interested to see where the discussion goes
<Hejsil> I think there was a discussion about changing the function syntax, so that you just bound anon functions to constants.
<Hejsil> const func = fn() void { }
<Hejsil> Something like that
<Hejsil> Though I can't find where that was
<jfo> yeah I really like that
<jfo> at least as an option
<jfo> oh god anything but `->` pls :) ptphpd
<jfo> actually I think there's conflation with C's dereferencing member access with that too though
<jfo> idk, glad we're thinking about it though!
<Hejsil> `->` was mostly just joking around
<Hejsil> Though I actually think the syntax makes things more clear
<Hejsil> instance->method(): Put instance into method, or something like that
<jfo> yeah I'm kidding too, it's not the worst thing in the world. it would be funny to take -> out of the return value definition and put it straight back in again somewhere else
<Hejsil> Oooh ye, totally forgot that lol
<Hejsil> Even though I still write -> by mistake
<jfo> ha
<jfo> SimonNa: ty!
<jfo> gtg to work, ttyl
<SimonNa> see you!
jfo has quit [Quit: WeeChat 1.9.1]
zesterer has quit [Quit: zesterer]
jfo has joined #zig
jfo has quit [Client Quit]
Hejsil has quit [Quit: Page closed]
hasen_judy has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Hejsil has joined #zig
hoppetosse has quit [Ping timeout: 260 seconds]
arBmind has joined #zig
hasen_judy has joined #zig
hoppetosse has joined #zig
hasen_judy has quit [Ping timeout: 265 seconds]
<MajorLag_> Jon Blow is doing compiler stuff on twitch right now if anyone is interested
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hopppetosse has joined #zig
hoppetosse has quit [Ping timeout: 265 seconds]
Hejsil has quit [Read error: Connection reset by peer]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 255 seconds]
<andrewrk> I wish he would use text to communicate information about jai
<andrewrk> videos take so long to consume
hopppetosse has quit [Ping timeout: 260 seconds]
zesterer has joined #zig
<MajorLag_> I agree. Can't cntrl-f a video.
davr0s has joined #zig
arBmind has quit [Ping timeout: 260 seconds]
hopppetosse has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<GitHub150> [zig] bnoordhuis opened pull request #750: DRY 'is slice?' conditionals in parser (master...dry-slice) https://git.io/vAJrY
<GitHub49> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAJrc
<GitHub49> zig/master 0090c2d Ben Noordhuis: DRY 'is slice?' conditionals in parser (#750)
<GitHub131> [zig] andrewrk closed pull request #750: DRY 'is slice?' conditionals in parser (master...dry-slice) https://git.io/vAJrY
dd3 has joined #zig
<zesterer> If people are worried about conflating "->" with C's pointer member access operator, why not use "=>" instead?
<andrewrk> I'm pretty happy with . instead of ->
<andrewrk> do people really want it changed?
arBmind has joined #zig
<zesterer> andrewrk: I mean for function declarations. i.e: fn add(a: i8, b: i8) => i8 { return a + b; }
<andrewrk> this would be to have void return types allow omitting the type
<andrewrk> and then an inferred error would be !=> void or would it be => !void ?
<andrewrk> and also we need to solve the ambiguity of fn foo() => error {}{}
Hejsil has joined #zig
<zesterer> andrewrk: I see no reason to change the current syntax other than the "readdition" of the "->" operator changed to "=>". Unless there is call to of course?
<andrewrk> if we're going to mess with the return type again I want to solve the syntax problem at the same time
klltkr has joined #zig
jfo has joined #zig
<jfo> andrewrk: the only thing I don't like about omitting -> on return types is that it makes function signatures look a little wierd on type declarations. ie struct { f: fn(u8) u8 }
<jfo> in that case the return type is kind of disconnected, but struct { f: (fn(u8) u8) } solves that for me so nbd
<zesterer> andrewrk: What syntax problem, sorry?
<andrewrk> zesterer, the ambiguity of fn foo() => error {}{}
<andrewrk> `symbol {}` could be the return type, or `symbol` could be the return type and {} the fn body
<andrewrk> most notably with error {} in the error-sets branch
<zesterer> andrewrk: I'm not quite sure what "symbol {}" is supposed to be here. {} is the void object, right?
<andrewrk> for example Foo {} instantiates a struct of type Foo
<andrewrk> fn bar() Foo {}
<andrewrk> fn bar() Foo {.a = 1} {}
<zesterer> andrewrk: The implication being that it's possible to have a value in a return type?
<andrewrk> with error {} (the empty error set) it's actually ambiguous
<zesterer> I don't understand why you'd want a value as part of the return type definition of a function at all.
<SimonNa> what was the original design decision behind 'fn bar() Foo' instead of 'fn bar(): Foo' or '-> Foo'?
<zesterer> SimonNa: "fn bar(): Foo" implies that the function *is* a Foo, rather than returning a foo
<andrewrk> zesterer, you wouldn't want a value. but you want a context free grammar, and whether something is a value or a type is context
Hejsil has quit [Quit: Leaving]
<zesterer> andrewrk: I agree. Why is "error {}" a type? Or am I myself falling to this ambiguity issue?
<SimonNa> yeah, thanks :)
<andrewrk> in the error-sets branch, error{} is an ErrorSet type, which has 0 members in the set
<andrewrk> which is important for calling functions which return an inferred error union type at compile time
<zesterer> I think using braces in types is a huge mistake, personally.
<andrewrk> what's your counter proposal?
<zesterer> I don't have one, but they're used as an indication of code, not types in most cases
<zesterer> Is it possible to use "<>" or "[]" instead?
<andrewrk> struct { } looks very comfortable to users of most other languages with the feature
<zesterer> But "struct{}" isn't a type
<andrewrk> yes it is
<zesterer> Which languages are you talking about? I've never seen that syntax used before
<andrewrk> C, Rust, Go
<zesterer> I've never seen that used in C as a type in my life. Can you give an example use case?
<SimonNa> zesterer: in C: struct { int x; } y; // for when you don't have to name the type
<SimonNa> and likewise struct{} y; is allowed in C
<zesterer> SimonNa: Okay fair enough. I'd forgotten about that.
<SimonNa> probably handy for throwaway local structs? I've never used it much :)
<zesterer> Still seems like appallingly ugly syntax though
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 276 seconds]
<GitHub27> [zig] bnoordhuis opened pull request #752: format struct pointers as "<typename>@<address>" (master...format-struct-pointers) https://git.io/vAJ9N
<GitHub46> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAJHc
<GitHub46> zig/master 79ad1d9 Ben Noordhuis: format struct pointers as "<typename>@<address>" (#752)
<GitHub53> [zig] andrewrk closed pull request #752: format struct pointers as "<typename>@<address>" (master...format-struct-pointers) https://git.io/vAJ9N
hopppetosse has quit [Ping timeout: 248 seconds]
<MajorLag_> anonymous structs aren't very useful in Zig. Try taking an anonymous struct as an argument, for instance. That's not a complaint, just an observation.
<andrewrk> I would agree with that observation. they're mostly useful for returning from a function
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hopppetosse has joined #zig
davr0s has joined #zig
<zesterer> andrewrk: Why must 'error {}' be the error set? Why not '%{}'?
<andrewrk> there's no `%` sigil in error-sets branch
<andrewrk> plus, error { } looks a lot like enum { } which is very similar to how it acts
<zesterer> Right
<zesterer> Perhaps requiring a single comma inside an empty set to differentiate it from a code block? "error {,}"
<zesterer> It's ugly, but it would fix the issue
arBmind has quit [Quit: Leaving.]
<andrewrk> I'm not satisfied with that
<GitHub90> [zig] bnoordhuis opened pull request #753: implement openSelfExe() on darwin (master...darwin-openselfexe) https://git.io/vAJhU
<GitHub51> [zig] jfo opened pull request #754: improve behavior of `zig build` (master...master) https://git.io/vAJhI
<GitHub161> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAJhR
<GitHub161> zig/master c88e6e8 Jeff Fowler: improve behavior of `zig build` (#754)...
<GitHub20> [zig] andrewrk closed pull request #754: improve behavior of `zig build` (master...master) https://git.io/vAJhI
dd3 has quit [Ping timeout: 256 seconds]
hasen_judy has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<zesterer> andrewrk: I wouldn't be either. Just throwing ideas out there ;)
<GitHub195> [zig] andrewrk closed pull request #753: implement openSelfExe() on darwin (master...darwin-openselfexe) https://git.io/vAJhU
<GitHub158> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAUfN
<GitHub158> zig/master dd20f55 Ben Noordhuis: implement openSelfExe() on darwin (#753)
jfo has quit [Ping timeout: 276 seconds]
davr0s has joined #zig
jfo has joined #zig
klltkr has quit [Ping timeout: 248 seconds]
dd3 has joined #zig