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
<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/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