ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zesterer has quit [Quit: zesterer]
zesterer has joined #zig
zesterer has quit [Client Quit]
zesterer has joined #zig
zesterer has quit [Quit: zesterer]
davr0s has joined #zig
tautologico has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
arBmind has joined #zig
davr0s has joined #zig
davr0s has quit [Ping timeout: 264 seconds]
cgag has quit [Ping timeout: 240 seconds]
cgag has joined #zig
tautologico has quit [Quit: Connection closed for inactivity]
<MajorLag_>
Lot of new keywords being proposed for Zig lately. Personal concern: if one of the goals is to keep the language small and understandable, the trade off doesn't seem worth it.
l1x has quit [Ping timeout: 255 seconds]
l1x has joined #zig
Hejsil has quit [Quit: Page closed]
arBmind has quit [Ping timeout: 256 seconds]
arBmind has joined #zig
<andrewrk>
MajorLag_, I share that concern
<andrewrk>
MajorLag_, what do you think about the coroutines proposal?
<MajorLag_>
I'm not qualified to offer an opinion. Coroutines aren't something I've ever used come to think of it. I do wonder if the type->type syntax couldn't be used more broadly though.
<MajorLag_>
Like: struct->{x: f32, y: f32}; union->{i: u32, f: f32}; tuple->{u32, []const u8}; This could solve the return type ambiguity.
<andrewrk>
that's a good observation
<andrewrk>
I do think that the biggest downside to the resource cleanup proposal is the increased size of the language
<andrewrk>
the only reason I would still consider it, is because requiring some kind of cleanup strategy - or having to specify "manual cleanup" - prevents bugs
<andrewrk>
"in practice it prevents bugs" is one of the only reasons to make the language bigger
<MajorLag_>
One thing I was wondering about that is, if I'm interfacing with C, there's no way the compiler knows what is being returned is a resource that needs cleanup or what the appropriate cleanup is, so I lose that protection anyway.
<MajorLag_>
I guess that sorta just comes with interfacing with C though.
davr0s has joined #zig
<MajorLag_>
Oh, and -> doesn't solve the return type ambiguity because you'd have the change the initialization, not the declaration.
<andrewrk>
true, kind of similar with pointers all having to be nullable if you parse a .h file
rohju has joined #zig
klltkr has joined #zig
<MajorLag_>
Is the cleanup function part of the type signature?
<andrewrk>
yes
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e_ has joined #zig
return0e has quit [Ping timeout: 252 seconds]
klltkr has quit [Ping timeout: 248 seconds]
arBmind has quit [Quit: Leaving.]
<GitHub136>
[zig] bnoordhuis opened pull request #783: name types inside functions after variable (master...fix675) https://git.io/vAg8a
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub20>
[zig] andrewrk closed pull request #783: name types inside functions after variable (master...fix675) https://git.io/vAg8a
<GitHub186>
zig/master b66547e Andrew Kelley: Merge pull request #783 from bnoordhuis/fix675...
<GitHub186>
zig/master 0845cbe Ben Noordhuis: name types inside functions after variable...