ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
<andrewrk> grinz, is your gist referring to #588 which is to be solved by #770?
<andrewrk> yes, interop with C and with common operating system API such as windows and linux
<andrewrk> I don't think winapi uses utf-8. see
<grinz> this is exactly why []null type is useless in that case
<grinz> andrewrk, yeah
<grinz> is there api to enumerate (and call by name) functions in scope/struct?
<andrewrk> grinz, []null for UTF-16 means it is terminated with u16(0)
<andrewrk> so it still works
<andrewrk> the full type would be: []null u16
<andrewrk> I don't think we have a function for that yet, but feel free to file an issue - it's planned to support that kind of reflection
<grinz> what about computed goto support?
<andrewrk> see this comment for computed goto:
<andrewrk> short summary is: let's come up with a use case where performance could be measurably improved by computed goto. and then let's try to write an LLVM optimization pass that detects the pattern and changes it to computed goto.
<andrewrk> if that doesn't work we can talk about adding computed goto to the language
<grinz> optimization pass is not good enough
<grinz> is has to be assert-like statement
<andrewrk> good enough in what sense?
<grinz> optimizations are too fragile
<grinz> you violate it rules and get bad performance without any warnings
<andrewrk> I agree with both of those statements, but I am not convinced that computed goto at the language level solves them
<andrewrk> if performance of a particular section of your code is a feature, then you need a test that makes sure that performance is maintained
<grinz> I am fine with while (true) switch construct as long as we have a way to get an error if compiler failed to transform to computed goto
hoppetosse has quit [Ping timeout: 260 seconds]
<andrewrk> I think this issue is worth discussing in the bug tracker if you would be willing to start that conversation
<GitHub60> [zig] andrewrk pushed 1 new commit to master:
<GitHub60> zig/master 8db7a14 Andrew Kelley: update errors section of docs...
<GitHub66> [zig] andrewrk closed pull request #768: document when to use error!type in function decl (master...func-decl-error)
<grinz> Well, I am still not sure I want to use clang for writing lexer. My latest experiment shown that compilers generally are not able to generate sane code for lexers
<grinz> You add one line and get new assembly for the whole function hurting performance by 20-30%
<andrewrk> grinz, are you considering having the lexer be in assembly?
<grinz> And you can always use C for the lexer as a workaround so its not much of a problem
<grinz> yup
<andrewrk> interesting. zig does have inline assembly, if that helps. it's mostly the same syntax as gcc and clang
<andrewrk> I'll be on later. bye
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 248 seconds]
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
<grinz> Is it possible to define function that takes value of arbitrary type T without passing T explicitly?
<MajorLag_> fn myFunc(thing: var)
<grinz> oh
<grinz> I was confused by error message "error: parameter of type '(integer literal)' requires comptime"
<grinz> When I tried myFunc(123)
<MajorLag_> been there.
<grinz> But i want that function to work with integer literals.
<grinz> Adding comptime breaks runtime values (obviously)
<grinz> Also it would be nice to take types as well
<grinz> And no function overloading, right?
<grinz> so many issues(
<MajorLag_> Yeah, unfortunately comptime is broken in many ways.
<grinz> No operator overloading?
<MajorLag_> Nope
<grinz> Why? Is it planned?
<MajorLag_> I don't know andrewrk or the rest of the community's reasoning. Personally I think it just obfuscates things. As far as I am aware there are no plans to implement it, but I'm relatively new to Zig myself so don't have a good knowledge of previous discussions.
<grinz> Then 1 + 2 should also be replaced with 1.add(2)
<grinz> Lack of operator overloading is major PITA when working with custom big integer / money / simd types
<MajorLag_> 1 + 2 is obvious though. There's no hidden allocation or computation involved.
<MajorLag_> You can't say that about overloaded operators.
<grinz> a | b is more obvious than _mm_or_si128(a, b)
<grinz> result &= (mouse_x < test.left) | (mouse_x > test.right) | (mouse_y < | (mouse_y > test.bottom);