<andrewrk>
and the bummer thing about this is that due to the fact that they made the protocol in the C library (libwayland in this example), you the video game creator targeting linux, will have to distribute multiple linux binaries.
<dec05eba>
that's one nice thing about x11. We can parse xcb xml files to generate zig client for x11 with 0 dependencies
<andrewrk>
dec05eba, x11 has the same issue that we're talking about though
<andrewrk>
it's not specific to wayland
<dec05eba>
what do you mean?
<andrewrk>
the bottom line is the vulkan/opengl drivers require being loaded into your process
<dec05eba>
ah graphics drivers...
<andrewrk>
anyway gamester worst case scenario, you end up having to create a lot of builds because of the state of graphics drivers on linux, but zig makes it easy with cross compiling
return0e has joined #zig
reductum has joined #zig
reductum has quit [Quit: WeeChat 2.4]
gamester has quit [Remote host closed the connection]
diltsman has joined #zig
<diltsman>
Anybody know if there are plans to support fixed-point types in Zig?
<shachaf>
I thought you meant recursive types but I guess there's a more straightforward interepretation in this context.
gamester has joined #zig
<diltsman>
I'm not certain that I have ever seen recursive types. Is there a language that supports them that I could look at?
darithorn has joined #zig
<shachaf>
I mean, things like struct Node { struct Node *next; }; are recursive.
<shachaf>
And they're probably the least fixed point of some functor or something, though Zig is not really the language for that sort of thing.
<andrewrk>
diltsman, the proposal gamester linked is not "accepted" which means that if you feel it belongs in the language, you are invited to explain your use case
darithorn has quit [Remote host closed the connection]
oky is now known as pbtt
pbtt is now known as oky
<tgschultz>
andrewrk, would the solution to #1810/#1923 do anything for #1386
<tgschultz>
?
<diltsman>
andrewrk: I can see that. I made a comment on it. I will think on it more in depth. I just know that many problem domains that I have worked in have used fixed-point arithmetic exclusively due to hardware limitations.
<andrewrk>
tgschultz, I think they're unrelated. the former has to do with runtime bookkeeping of error return traces; the latter has to do with analysis of error set types
<tgschultz>
darn
kristate has joined #zig
kristate has quit [Read error: Connection reset by peer]
kristate has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
<tgschultz>
I contend that an empty errorset is not the same as having no errorset, so it should be inferable. Not having it be inferable has forced workaround code into interfaces.
reductum has joined #zig
<emekankurumeh[m]>
I agree
reductum has quit [Quit: WeeChat 2.4]
kristate has quit [Remote host closed the connection]
_whitelogger has joined #zig
dewf has quit [Quit: Leaving]
scientes has joined #zig
kristate has joined #zig
scientes has quit [Ping timeout: 245 seconds]
kristate_ has joined #zig
kristate has quit [Ping timeout: 255 seconds]
<andrewrk>
I also agree
hgst has joined #zig
<tgschultz>
oh, for some reaosn I'd missed that 1386 was marked as a bug. Thought there was some reasoning behind it acting the way it did that was still under consideration.
<andrewrk>
tgschultz, I'm just trying to make it so that your use case works (which currently doesn't and requires a workaround) and the status quo use case continues to work (you forgot to return a possible error, or refactored a function to no longer return error and forgot to change return type)
<tgschultz>
aside from the fact that we're not getting two bugfixes for the price of one, no big deal.
<andrewrk>
to answer your question again
<andrewrk>
> would the solution to #1810/#1923 do anything for #1386
<andrewrk>
I absolutely think that #1386 and #1810 are related, quite possibly the same issue
<andrewrk>
I'll make sure to examine them together, when working on it
<andrewrk>
with this in mind, does your `try`/`catch` question still apply to #1923?
MajorLag has joined #zig
<andrewrk>
unrelated, I'm considering deleting `use`. it just won't be available. but you would be able to use `pub foo;` to "splat" a struct to @import()ers
<andrewrk>
but it wouldn't apply to the current file
tgschultz has quit [Ping timeout: 244 seconds]
MajorLag is now known as tgschultz
<andrewrk>
hmm, that's problematic. you could still get the old behavior by introducing a file as a layer of indirection
<andrewrk>
probably status quo will stay then. but I guess it will be a compile error if `use` occurs in generic structs or functions
<andrewrk>
idk, I'll play with it.
Avila has joined #zig
<tgschultz>
the try/catch thing only applied to the errorset inference
<tgschultz>
use is... well, I can see both how it is a problem and how it isn't.
<daurnimator>
andrewrk: and then combine with making a struct dynamically at comptime
Zaab1t has joined #zig
Ichorio has joined #zig
<emekankurumeh[m]>
daurnimator: for dynamic structs at comptime, `@reify` was proposed
<daurnimator>
emekankurumeh[m]: if you think about the idea of "a file is a struct body", then you *are* building a struct one field at a time.
scientes has quit [Remote host closed the connection]
scientes has joined #zig
<emekankurumeh[m]>
true
scientes has quit [Remote host closed the connection]
dewf has joined #zig
<bheads>
For #2014 would it be simpler to just have pub @useImport("c.zig") over renaming use to usenamespace
scientes has joined #zig
<andrewrk>
bheads, I covered that question in the proposal
shawn_ has joined #zig
<bheads>
Not sure I see that
scientes has quit [Ping timeout: 257 seconds]
<andrewrk>
to answer your question directly: no, it would not be simpler
dec05eba has left #zig ["User left"]
<andrewrk>
renaming a keyword is one of the simplest modifications possible. if you're saying it would simplify the semantics of the language, I fail to see how it does that
<bheads>
I get that renaming use to usingnamespace is a easy fix, but removing a keyword does simplify the language
<bheads>
was just a thought
Avila has quit [Quit: Leaving]
<andrewrk>
in this case the builtin has important side effects one has to be aware of. this makes it equivalent (or perhaps worse) than a keyword in terms of semantic simplicity
<andrewrk>
bheads, sorry, I thought at first you meant special casing the use case of "pub use"
<bheads>
ah, gotcha
<bheads>
yeah, I was thinking use can really change a lot of things
<andrewrk>
that's actually an important use case though
shawn_ has quit [Ping timeout: 240 seconds]
<andrewrk>
not the std lib in particular, but imagine depending on a package, and adding some extra functionality to it
<bheads>
right (I just pick std cause its short to type)
<andrewrk>
maybe something like a "full windows.h" package which does `pub usingnamespace @import("std").os.windows;`
<andrewrk>
and then adds all the decls that zig does not include because they are unnecessary
<bheads>
exactly
wootehfoot has joined #zig
<gamester>
I doubt that people who dislike "obj.method()" pattern and would rather write method(obj) would subject themselves to File.method(obj) for every method in their project, nor would they pull every method out by hand: const method = File.method; What remains for them is not using zig or littering their code with "usingnamespace" which is more verbose now.
<gamester>
I like obj.method() myself and for that I first do const Object = @import("file.zig").Object; as we all do
<andrewrk>
gamester, the only difference from C is that namespaces are mandatory, and instead of a `prefix_` convention, it's `prefix.` in zig
<andrewrk>
I don't think there's any room to complain, for those coming from C
<andrewrk>
you can even rename the prefix like this: `const p = @import("libpng");`
<tgschultz>
you can kinda build a struct dynamically at comptime. you have to reference the fields in code using getters and setters though.
<andrewrk>
s/mandatory/automatically created for files/
<gamester>
andrewrk: if C people use a prefix, it could be anything, such as a per project prefix. The file name could be completely meaningless
<tgschultz>
the filename is only relevant to @import()
<gamester>
err I mean, it would hold so little meaning that having a prefix based on it would be confusing
<andrewrk>
gamester, are you advocating for changing something?
<gamester>
Is it possible to import multiple files into a single prefix?
<andrewrk>
yes, just use multiple usingnamespace declarations in the same file
<andrewrk>
and then `const x = @This();`
<andrewrk>
or you can @import("thefile.zig") from another file if you did `pub usingnamespace`
<andrewrk>
the thing with @This() isn't necessary but you could do it if you anticipated cutting & pasting code to somewhere outside the file
<andrewrk>
until that's done zig does not have any level of support for OpenBSD
<WilhelmVonWeiner>
how would I check that out?
<WilhelmVonWeiner>
I don't use git often more than `git clone` kekeke
<andrewrk>
you would clone Aversiste's repository and then checkout the `openbsd` branch. you can find that out from "Aversiste wants to merge 5 commits into ziglang:master from Aversiste:openbsd" at the top
<andrewrk>
but please note the official answer to your question is: Zig does not support OpenBSD yet
<DutchGh0st>
while on Manjaro I have 0.3, but some version later than the actual release
<DutchGh0st>
0.3.0+ba361f31 to be exact
<andrewrk>
there have been quite a few improvements since then :)
<DutchGh0st>
yeahh...I should keep it all up to date :3
<DutchGh0st>
but on the other hand, isn't 0.4 coming kinda soon-ish?
<andrewrk>
yes, in march
<DutchGh0st>
woopwoop
<DutchGh0st>
oh, I also wondered a couple days ago, coroutines...They are still being worked on, but will there be some mechanism to prevent putting the coroutine in an invalid state by `moving` it?
<DutchGh0st>
or won't there be the issue of like ' ohhh, but if I move the thing at this point I invalidate references it has to itself and blahblahblah' ?
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
hard to say for sure but it's my intention that that mistake will be difficult to make, ideally with compile errors, but perhaps with debug runtime safety checking
<andrewrk>
that's definitely an important consideration in the design
<DutchGh0st>
I actually wondered if you could add like an extra field if you are 'unsafe' to be moved, and then have a special pointer type that can only give you a mutable pointer if your struct doesnt have the extra field
<DutchGh0st>
and then coro's could only be advances trough the special ptr type
<DutchGh0st>
but maybe there's another better way other than this pin-like behaviour :)
<andrewrk>
that's something that will become more clear how to do once copy-elision is done
<DutchGh0st>
ah yeahh you're bussy with that
<DutchGh0st>
in std.meta, is there a way to make a query like 'hey, does this type have this field (indirectly)` ?
<DutchGh0st>
by indirect I mean you might ask for a field "Bar" , but because of all the nesting, only the most deep type has a field "Bar"
<tgschultz>
Did anyone answe DutchGh0st's question about std.meta? If not, and if I understand the question correctly, then no. There isn't a convenience function for recursive field enumeration.
wootehfoot has joined #zig
tgschultz has quit [Ping timeout: 246 seconds]
tgschultz has joined #zig
donpdonp has left #zig ["WeeChat 2.0.1"]
hgst has quit [Quit: WeeChat 2.4]
redj has quit [Read error: Connection reset by peer]
tgschultz has quit [Ping timeout: 245 seconds]
wootehfoot has quit [Read error: Connection reset by peer]