00:43 <andrewrk> defenestrator_, []u8

00:44 <andrewrk> string literals are [N]u8 where N is the length of the array. [N]u8 can implicitly cast to []const u8

00:52 <defenestrator_> So when I try, say "var string = "Hello world!"; var s: []u8 = undefined;" I have to say "s = string[0..];" instead of "s = string;", and I also can't assign a string literal directly to "s" either...is that correct?

00:54 <andrewrk> defenestrator_, https://clbin.com/EAs8u

00:54 <andrewrk> what are you trying to do?

00:59 <defenestrator_> I guess my larger question is initializing string pointers to string literals, e.g. in a struct:

00:59 <defenestrator_> https://clbin.com/rjpmo

01:00 <defenestrator_> I get "error: expected type '[]u8', found '[12]u8'"

01:04 <andrewrk> defenestrator_, []u8 is a mutable pointer and a length. you can't mutate string literal data since it's stored in the constant section of the binary

01:05 <andrewrk> so your choices are: 1. make it string: []const u8 or 2. create a copy of the string literal on the heap and put that in the struct

01:11 <defenestrator_> Ok, thanks...so it looks like std.mem.dupe is the best way to do that if I need option 2?

01:33 <andrewrk> defenestrator_, yep, try that

01:33 <andrewrk> and then have a plan for freeing it, or use something like ArenaAllocator

01:48 <defenestrator_> Thanks!

16:14 <GitHub197> [zig] andrewrk pushed 1 new commit to master: https://git.io/vAiB5

16:14 <GitHub197> zig/master 439621e Andrew Kelley: remove signal hanlding stuff from std.os.ChildProcess

17:00 <hoppetosse> andrewrk: what do you have in mind for packed enums?

17:01 <hoppetosse> What could the compiler do to non-packed enums?

17:01 <andrewrk> hoppetosse, I don't remember. packed enums might not make sense

17:02 <andrewrk> you can put a normal enum in a packed struct if you specify the enum tag type

17:03 <hoppetosse> We had a brief exchange about it in the enum array issue

17:04 <hoppetosse> We were talking about ordering and indexing of members, and I wasn't sure what the packed enum could be

18:13 <andrewrk> hoppetosse, yeah I've been following along

18:13 <andrewrk> I've been really focused on coroutines

18:14 <hoppetosse> andrewrk: I'm excited to see that!

18:15 <hoppetosse> There's also been discussion about the function return syntax, how do you think generators are going to interact with that?

18:16 <andrewrk> where's the function return syntax discussion?

18:16 <hoppetosse> As for the async/await/promise stuff, it's looking great. I'm surprised you managed to get the clean keyword in there without cluttering it too much

18:17 <hoppetosse> https://github.com/zig-lang/zig/issues/760

18:17 <hoppetosse> It's the return type discussion

18:17 <hoppetosse> no-one's mentioned generators in there yet, I'm just bringing it up now

18:19 <andrewrk> thanks

18:52 <hoppetosse> andrewrk: I love what you've done with that => hahaha

18:52 <hoppetosse> I'll be honest, I was gonna suggest something like this back when people complained that the language was too noisy/full of sybols

18:53 <hoppetosse> I'd love to rid my code of some parentheses

18:53 <andrewrk> hoppetosse, bottom line is we solve this same disambiguation in other places with (), so we either need to require () in return types, or whatever fixes the return type issue will also let us drop () on if, while, switch, for

18:55 <hoppetosse> That sounds like a pretty good position to be in.

20:03 <hoppetosse> andrewrk: I've added some ideas for container initialization. I'm off to dinner in a bit, but I'll elaborate further

20:08 <andrewrk> thanks!

20:16 <hoppetosse> updated with a few more notes

22:06 <hoppetosse> andrewrk: the "fn foo() error { }" ambiguity is there because of the declaration syntax, correct?

22:07 <andrewrk> correct

22:07 <hoppetosse> in the "fn foo() A { }" example, there shouldn't be any ambiguity since you wouldn't expect an initialization there, so as long as A isn't error, it 's fine

22:08 <andrewrk> you could expect an initialization there

22:08 <andrewrk> fn foo() error{} {}

22:08 <andrewrk> error{} is an empty error set

22:08 <hoppetosse> ok, but not fn foo() UserStruct { }

22:09 <hoppetosse> I've been refining my thoughts, and I think I have something workable

22:09 <hoppetosse> I'll post it up now so I can be clearer

22:10 <andrewrk> ok

22:13 <hoppetosse> Declaration syntax changes to use parentheses instead of curly brackets, and square brackets instead of parentheses. Initialization requires new (T) { .fields = t }

22:15 <hoppetosse> What I was trying to ask is, if there is no ambiguity caused by status quo initialization it can stay the same.

22:16 <hoppetosse> because if error {} is the only valid initialization, we can make it like a declaration instead and remove the ambiguity

22:16 <hoppetosse> ie: error sets are declared/initialized with parentheses

22:16 <hoppetosse> fn foo() error(NoMem)!void {}

22:17 <hoppetosse> Just like an enum's declaration is pretty much it's initialization, an error declaration is also its initialization

22:18 <hoppetosse> I'm sorry for how fragmented that came out.

22:23 <hoppetosse> updated with function declarations

22:43 <GitHub50> [zig] bnoordhuis opened pull request #796: allow implicit cast from &const to ?&const &const (master...fix731-more) https://git.io/vAPG1

22:48 <andrewrk> hoppetosse, a(b) is an explicit cast to type 'a'

22:49 <andrewrk> said another way, a(b) is a function call, and if a is a type then it's an explicit cast

22:49 <andrewrk> error(foo) already has meaning

22:52 <MajorLag> Man, I'm getting real sick of "error: link failed". This is supposed to be fixed with the latest LLVM right?

23:09 <andrewrk> MajorLag, yeah, which is to be released something like tomorrow

23:09 <andrewrk> I'll merge llvm6 branch into master the same day

23:10 <andrewrk> have you been using the appveyor artifacts?