16:21 <skyfex> @andrewrk: Little-endian packed struct tested, and typed enums both tested and works well for me :)

16:21 <andrewrk> great!

16:22 <andrewrk> and now the biggest issue is the reserved field thing right?

16:22 <skyfex> Hah, yes, I was just about to mention that :)

16:23 <skyfex> Also, it's a bit annoying to type out the whole enum value. It'd be great if I could type just "Connected" instead of "nrf.PinCnfInput.Connected"

16:23 <skyfex> I haven't checked the issues, but I think it might have been discussed already?

16:24 <andrewrk> I think there is not a discussion for that

16:26 <skyfex> K, gotta leave now, but maybe I'll open an issue for that later. I'm not sure if it's in the Zig style, but it'd be good to get some comments I suppose

16:26 <andrewrk> sure, might as well document the reasoning in either case

16:30 <skyfex> I see it as type-inference when declaring variables: not strictly necessary, could sometimes create a bit confusion, but generally worth it. Using enums should really be encouraged over non-descriptive integers or booleans

16:31 <andrewrk> encouraging enum use is a good argument for the feature

16:32 <andrewrk> I was thinking it might make sense to, for example, in switches, allow `.Connected` and the `.` would implicitly be accessing the type you switched on

16:32 <andrewrk> maybe also for function calls with enum parameters

16:34 <skyfex> it would make sense with this proposal as well: https://github.com/zig-lang/zig/issues/661

16:34 <andrewrk> good point

16:34 <andrewrk> really good point

16:35 <andrewrk> and for this one: https://github.com/zig-lang/zig/issues/649

16:35 <andrewrk> I think I'm sold

17:02 <aiwakura> hi andrewrk

17:02 <aiwakura> let's the madness begin

17:03 <andrewrk> hi aiwakura

17:04 <aiwakura> so %return -> try, correct?

17:04 <andrewrk> correct

17:04 <andrewrk> and ` %% ` -> ` catch `

17:16 <GitHub108> [zig] AndreaOrru pushed 1 new commit to master: https://git.io/vNLuZ

17:16 <GitHub108> zig/master 98a95cc Andrea Orru: exit, createThread for zen

17:38 <andrewrk> skyfex, thanks for the writeup

21:07 <aiwakura> andrewrk are you going to get rid of ?? too?

21:08 <andrewrk> I have no plans in that regard

21:08 <andrewrk> good point though, it's an example of non-keyword control flow

21:08 <andrewrk> I believe C# has a precedent for ?? having the same behaivor as zig

21:46 <jjido> Any chance that a %% b would be allowed again ? I don't feel too good writing a catch b when b is not a closure on the error

21:54 <andrewrk> jjido, actually it is a closure on the error: a catch |err| b

21:54 <andrewrk> the |err| is optional

21:55 <andrewrk> I'm responding to your comment on #632

22:03 <jjido> andrewrk: yes it is but the syntax hides it (unfortunately)

22:30 <andrewrk> jjido, can you elaborate? what do you mean the syntax hides it?

22:34 <jjido> While b expands to |err| b internally, when a human reads to program they see a catch b. That is what is commonly called "syntactic sugar" and in this case it makes the program harder to understand instead of easier

22:35 <andrewrk> jjido, let me make sure you understand this change

22:35 <andrewrk> `

22:35 <andrewrk> `%%` became `catch`. no other differences

22:35 <jjido> If a %% b is not available I would write a catch |_| b

22:36 <andrewrk> that is valid

22:36 <jjido> The difference is clear

22:36 <andrewrk> are you suggesting the |_| should be required?

22:36 <jjido> Yes that would make more sense with the catch keyword

22:36 <andrewrk> ok I see what you are saying now

22:37 <andrewrk> because without the |_| it sounds like you are catching `b`

22:38 <andrewrk> I think that is worth considering