<fengb>
And theres no methods on the top level so it;s through cond.impl
<fengb>
Oh boy that's a big change. Maybe I'll wait for now >_>
lanodan has quit [Ping timeout: 272 seconds]
jukan has joined #zig
lanodan has joined #zig
Pistahh has quit [Ping timeout: 240 seconds]
jukan_ has quit [Ping timeout: 265 seconds]
<daurnimator>
Is there a proposal around already for an `else at comptime` block for `asm`?
<daurnimator>
i.e. a block of code that would run instead of the asm, if the code was reached at comptime?
cole-h has quit [Ping timeout: 256 seconds]
slact has quit [Ping timeout: 260 seconds]
ur5us_ has joined #zig
gazler_ has quit [Ping timeout: 240 seconds]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
gazler_ has joined #zig
<Snektron>
asm statements are constexpr in C++20 for this reason
ur5us_ has quit [Ping timeout: 246 seconds]
cCCCCcccccCCc has joined #zig
<daurnimator>
Snektron: huh?
<daurnimator>
Snektron: I'm trying to think of a reasonable alternative to an `@isComptime()` builtin so that we can have optimized assembly without making a funciton unavailable at comptime
kbd has joined #zig
nvmd has joined #zig
nvmd has quit [Client Quit]
nvmd has joined #zig
casaca has joined #zig
nvmd has quit [Quit: Later nerds.]
bitmapper has quit [Quit: Connection closed for inactivity]
mht-technology has joined #zig
<Snektron>
In C++ it works like this afaik: asm statements are allowed in constexpr functions but arent allowed to execute. This allows `if constexpr (std::is_constant_evaluated()) comptime_implementation()`.
<Snektron>
So thats basically the isComptime approach
mht has quit [Ping timeout: 256 seconds]
ifreund has quit [Ping timeout: 256 seconds]
<Snektron>
Anyway, my understanding was that this is what builtins should be used for? like @sqrt and stuff. I also understand that this falls short, though
ifreund has joined #zig
slact has joined #zig
ur5us_ has joined #zig
marler8997 has quit [Read error: Connection reset by peer]
sebonirc has quit [Ping timeout: 260 seconds]
<daurnimator>
Snektron: in e.g. the gimli implementation, we have a general algorithm in pure-zig, and an optimized version for x86_64.
<daurnimator>
Snektron: the trouble is, that means that it doesn't work at comptime when targeting x86_64
<Snektron>
What about specialized syntax that allows one to run asm or normal code at comptime
<Snektron>
So basically a restricted version of isComptime
<Snektron>
Although that would allow custom implementation of isComptime fairly easily
ur5us_ has quit [Ping timeout: 264 seconds]
factormystic has quit [Read error: Connection reset by peer]
factormystic has joined #zig
v0idify has quit [Ping timeout: 268 seconds]
v0idify has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<daurnimator>
Snektron: yeah. that's what I was proposing: essentially an `else` block on `asm` blocks....
sord937 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
ur5us_ has joined #zig
cole-h has joined #zig
Stephie has quit [Quit: Fuck this shit, I'm out!]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
Stephie has joined #zig
tnorth_ has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
nycex- has joined #zig
nycex has quit [Remote host closed the connection]
<kameliya[m]>
hm. I feel like `comptime { std.testing.refAllDecls(@import("exports.zig")); }` is not the way to force my exports to get reffed. what am I missing?
ur5us_ has quit [Ping timeout: 264 seconds]
jukan has quit [Ping timeout: 246 seconds]
jukan has joined #zig
jukan has quit [Ping timeout: 256 seconds]
<ifreund>
kameliya[m]: refAllDecls() will only run if bulit in test mode
<ifreund>
comptime { _ = @import("exports.zig"); } should do it
<kameliya[m]>
ahh, thank you!
<kameliya[m]>
that did the trick!
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
xackus has joined #zig
Xatenev has joined #zig
tnorth_ has quit [Ping timeout: 264 seconds]
ur5us_ has joined #zig
jukan has joined #zig
Snetry- has joined #zig
Snetry has quit [Ping timeout: 256 seconds]
jukan has quit [Ping timeout: 256 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
tnorth_ has joined #zig
nycex has quit [Remote host closed the connection]
nycex- has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 264 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
nycex- has joined #zig
nycex has quit [Remote host closed the connection]
suskun has joined #zig
Xatenev has quit [Ping timeout: 246 seconds]
dumenci has joined #zig
suskun has quit [Ping timeout: 246 seconds]
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
jukan has joined #zig
zags has joined #zig
<zags>
Is there a way to test comptime functions? I want to make sure compileError is hit in certain cases.
<ifreund>
we don't have a way to test for compile error currently, though there's an open issue for that iirc
<zags>
ok cool
jukan has quit [Ping timeout: 240 seconds]
nycex- has joined #zig
nycex has quit [Remote host closed the connection]
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
<zags>
Is there logic to @TypeOf and @typeInfo having different case on first letter?
<dutchie>
yes. @TypeOf(...) is a type, and @typeInfo(...) is a value
<dutchie>
(obviously types being values blurs the lines a little, but)
v0idify has joined #zig
<g-w1>
functions that return types (usually generics) are capical because Types are capital
<dutchie>
you can write `fn foo(x: anytype) @TypeOf(x)` but not `fn foo(x: anytype) @typeInfo(x)`
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
midgard has quit [Ping timeout: 260 seconds]
v_m_v has joined #zig
donniewest has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
midgard has joined #zig
bitmapper has joined #zig
frett27_ has joined #zig
BaroqueLarouche has quit [Quit: Bridge terminating on SIGTERM]
protheory8-new-m has quit [Quit: Bridge terminating on SIGTERM]
Nypsie[m] has quit [Quit: Bridge terminating on SIGTERM]
ifreund_ has quit [Quit: Bridge terminating on SIGTERM]
ziguana[m] has quit [Quit: Bridge terminating on SIGTERM]
vpzom has quit [Quit: Bridge terminating on SIGTERM]
mtiljeset[m] has quit [Quit: Bridge terminating on SIGTERM]
pafmaf[m] has quit [Quit: Bridge terminating on SIGTERM]
kameliya[m] has quit [Quit: Bridge terminating on SIGTERM]
ugla has quit [Quit: Bridge terminating on SIGTERM]
fengb has quit [Quit: Bridge terminating on SIGTERM]
Snektron has quit [Quit: Bridge terminating on SIGTERM]
Bastian[m] has quit [Quit: Bridge terminating on SIGTERM]
jaens[m] has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
kameliya[m] has joined #zig
Akuli has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
sebonirc has joined #zig
ugla has joined #zig
BitPuffin has joined #zig
ifreund_ has joined #zig
siraben has joined #zig
ziguana[m] has joined #zig
jaens[m] has joined #zig
dtz has joined #zig
fengb has joined #zig
D3zmodos has joined #zig
Nypsie[m] has joined #zig
mtiljeset[m] has joined #zig
protheory8-new-m has joined #zig
vpzom has joined #zig
jzck has joined #zig
Snektron has joined #zig
Demos[m] has joined #zig
BaroqueLarouche has joined #zig
pafmaf[m] has joined #zig
jukan has joined #zig
frett27_ has quit [Ping timeout: 264 seconds]
vcarvalho has joined #zig
zags has quit [Ping timeout: 272 seconds]
waleee-cl has joined #zig
Demos[m] has quit [Quit: Idle for 30+ days]
jzck has quit [Quit: Idle for 30+ days]
D3zmodos has quit [Quit: Idle for 30+ days]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
g-w1 has quit [Quit: WeeChat 2.7.1]
jacob3 has joined #zig
jacob3 is now known as g-w1
frett27_ has joined #zig
nvmd has joined #zig
hnOsmium0001 has joined #zig
nvmd has quit [Ping timeout: 256 seconds]
nvmd has joined #zig
lucid_0x80 has joined #zig
tnorth_ has quit [Ping timeout: 260 seconds]
dumenci has quit [Ping timeout: 256 seconds]
v_m_v has quit [Remote host closed the connection]
nvmd has quit [Quit: Later nerds.]
jukan has quit [Read error: Connection reset by peer]
jukan has joined #zig
nvmd has joined #zig
kbd has joined #zig
lucid_0x80 has quit [Ping timeout: 246 seconds]
nycex- has joined #zig
nycex has quit [Quit: Quit]
DarkUranium has quit [Read error: Connection reset by peer]
DarkUranium has joined #zig
jukan_ has joined #zig
jukan has quit [Ping timeout: 246 seconds]
<mjsir911>
On the build from source instructions it mentions that if you want to use pre-built zig the libraries need to be built with zig. How do zig built archives/libs differ from them built with other compilers? I would've assumed the same symbols get exported either way, do calling conventions differ?
<ifreund>
that's a issue that plagues all C++ linkingn
nvmd has quit [Quit: Later nerds.]
<ifreund>
the C++ ABI is implementation dependant so you need to use the same compiler for any two objects you want to link
<mjsir911>
ah, is it the name mangling?
<mjsir911>
But I see, thank you ifreund
<ifreund>
I'm not sure on the details, and I'm not sure I want to know more :D
<ifreund>
no problem!
wootehfoot has joined #zig
wootehfoot has quit [Remote host closed the connection]
wootehfoot has joined #zig
Akuli has quit [Ping timeout: 258 seconds]
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
Akuli has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
nvmd has joined #zig
<pixelherodev>
andrewrk: you commented of 5521 that usingnamespace is discouraged outside organization of a public API, right?
<pixelherodev>
s/of/on//
<andrewrk>
right
<pixelherodev>
Hmm, need to pop open stdlib real quick to let the thought develop a bit more, might open a related proposal soon
<ikskuh>
andrewrk: how is your stance on 6709?
<pixelherodev>
...I should take a minute to write a bot for this channel for %%6709 :O
<andrewrk>
ifreund, are you aware of std.meta.eql?
<ikskuh>
i'd like to convince you of "let's do it"
<andrewrk>
ifreund, oops never mind I should have read your whole description
<ifreund>
andrewrk: am I stupid and std.meta.eql follows pointers?
<ifreund>
oh ok :)
<ifreund>
I guess std.meta.deepEql() would be an alternative place to put this
fritchie has quit [Remote host closed the connection]
fritchie has joined #zig
Akuli has quit [Ping timeout: 246 seconds]
ur5us_ has joined #zig
<pixelherodev>
ikskuh: one note on your example (which can be positive or negative depending on perspective): it moves more logic into stdlib and away from the language and, especially, conventions
<pixelherodev>
If a library defines an interface, that library now either depends on stdlib or breaks conventions
moo has joined #zig
<pixelherodev>
If our stance is, "You shouldn't be using a custom stdlib, but should use e.g. BYOS if needed instead," then this perfectly fine - though freestanding code without stdlib can definitely make sense, breaking conventions is probably okay there, but it means that the right way to use interfaces now depends on the use case for your code
<pixelherodev>
ikskuh: I think the focus needs to be less on the use cases and more on the impacts. The use cases are clearly improved by the proposal, the question is whether it has any harmful or undesirable side effects
wootehfoot has quit [Ping timeout: 256 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<ifreund>
pixelherodev: Isn't one of the major selling points of zig that the std is totally suitable for freestanding?
jjido has quit [Quit: Connection closed for inactivity]
<ikskuh>
pixelherodev: even then, removing a burden from the language and shifting it to stdlib also means we can make that stuff "external library only"
nycex has quit [Remote host closed the connection]
nycex has joined #zig
frett27_ has quit [Ping timeout: 272 seconds]
Akuli has joined #zig
<mikdusan>
lordy. someone got macos 10.15 (x86_64) running on ipad pro (arm64) using I'm guessing rosetta 2 x86_64 translator
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<pixelherodev>
ifreund: yes
<pixelherodev>
ifreund: but it doesn't need to be used, and not using it reduces potential attack surface, for instance
<pixelherodev>
(yes, lazy eval; that just means you don't know what parts of std you need to evaluate!)
terinjokes has joined #zig
zags has joined #zig
<zags>
I'd like to pass a function to a function (like a C callback really, but no C involved here), but I struggle finding the syntax. Anyone got an example?
<Gliptic>
the type is just: fn(parameters...) returntype
<Gliptic>
and you just pass the function by name, no special syntax there
<Gliptic>
the parameters... would be the list of types
<zags>
Ok, so easy it tripped me up :D
<zags>
Thanks
<zags>
Oh, and also... can I declare a parameter as taking any struct containing a function with a given signature?
<ifreund>
zags: the way to do that is to use anytype
<ifreund>
if the struct doesn't have a function with the required signature you'll get a compile error when you try to use that signature
<zags>
Interesting
<ifreund>
this is how std.io.Reader/Writer work for example
<zags>
Powerful!
<ifreund>
comptime duck-typing yeah :D
<Gliptic>
some say too powerful (*cough* C++ templates)
<zags>
heh
moo has quit [Ping timeout: 246 seconds]
jukan has joined #zig
jukan_ has quit [Ping timeout: 265 seconds]
Akuli has quit [Quit: Leaving]
sord937 has quit [Quit: sord937]
<terinjokes>
is there an example of using anytype with std.io.Reader? i've been doing `comptime ReaderType: type`
<zags>
A downside with anytype is that it makes for bad API documentation
<ifreund>
zags: agreed
<zags>
Yeah, in this case, I unfortunately will need to expose it, so it would be nice to document the signature
<ifreund>
there have been some proposals to improve that but nothing that's managed to solve it in a satisfactory way yet
<zags>
I see
<zags>
I intuitively tried things like this :) pub fn compute(callback: .{callable: fn lambda([]const u8) u32}) void {
cole-h has joined #zig
<zags>
I intuitively tried things like this :) pub fn compute(callback: .{callable: fn([]const u8) u32}) void {
<ifreund>
note that you can type check the argument in whatever way you like within your function using @typeInfo()
<zags>
yeah, noticed that, very nice - my concern is mostly with providing a clean interface. Zig will get there!
<ifreund>
zags: I'm not happy with the current situation either, I just haven't been able to think of anything better
<zags>
A tough one. btw, that json example on the home page confused me for a long time, I read the backslashes as comments because of the green :D Damnit, that took me too long.
<terinjokes>
i forget where I pulled my current code from (i think std?), but taking `comptime T: type` and returning a struct with a function member that takes T as a parameter
<ifreund>
zags: yeah, maybe that could use a // comment saying it's a multiline string, zig's syntax for them is a bit atypical
<ifreund>
I kinda love it though for its simplicity
<zags>
yeah it's nice, i guess it was mostly the "this is a comment" coloring that threw me off, maybe because I use green comments haha
<zags>
the vscode rendering of the same code is much easier
<ifreund>
which matches the color of the "std" string just above
<zags>
ifreund: on the webpage?
<ifreund>
yeah
<ifreund>
are you in dark mode or something?
<zags>
weird, I'm in darkmode on macos yeah, does it pick that up?
<ifreund>
yeah
<zags>
oh well :D
nycex has quit [Remote host closed the connection]
<zags>
the darkmode vscode color scheme makes much more sense
nycex has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<ifreund>
I'm not really sure where the website highlighting comes from, but you could open an issue here if you feel strongly about it: https://github.com/ziglang/www.ziglang.org/
<zags>
nah, it's not important in the grand scheme of things
<zags>
pub doesn't mean what I think it did. I'm able to call a non-pub function inside a struct from the outside. So it's more about linker visibility?
<ifreund>
pub is file-based
<zags>
hm so what does it mean to put pub on a struct function?
<ifreund>
it means that function will be visible when using that struct in a different file
<zags>
alright
<zags>
docs appear to be mute on the topic, unless I'm missing something, so thanks :)
<ifreund>
I wonder what ziglearn.org has to say
<zags>
Is that official?
<zags>
It says "The built-in function @import takes in a file, and gives you a struct type based on that file. All declarations labelled as pub (for public) will end up in this struct type, ready for use"
<zags>
which is good enough
<ifreund>
ziglearn was started by a community member so not really "official" no
<ifreund>
quite a good resource though
<kameliya[m]>
officially there's no such thing as official per se
<terinjokes>
but it's much easier to read through the first time, before getting into the main docs (and it is linked to from ziglang.org)
<kameliya[m]>
(from ziglang.org: "Anyone is free to start and maintain their own space for the community to gather. There is no concept of “official” or “unofficial”, however, each gathering place has its own moderators and rules.")
<zags>
Good to know
<zags>
I'm more interested in "kept up to date" than official :)
<zags>
and correct
nvmd has joined #zig
<ifreund>
ziglearn should be at least as up to date and correct as the "official" language reference :D
<zags>
I see :)
ur5us_ has quit [Ping timeout: 264 seconds]
<Gliptic>
is there a debug print function that only prints when you run in Debug compilation mode?
<g-w1>
std.log.info
<ifreund>
std.log.debug would be more suitable
<ifreund>
info is intended for status messages
<Gliptic>
aha, I didn't make that connection
<zags>
so @hasDecl can tell me about the presence of a function, is there also a way to check parameter and return types?
<ifreund>
zags: @typeInfo()
<zags>
Looked at it, docs scarse. But that puts me on the right track, thanks
<ifreund>
you'll probably also want to check out the definition of TypeInfo in std/builtin.zig
<kameliya[m]>
^ there's an abundance of information to use, just not well-documented at the moment. you can go very far with comptime reflection.
<zags>
cool, a utility for checking signatures that lowers to @typeInfo would be awesome, but will figure it out
<ifreund>
zags: std.meta.trait
<ifreund>
though actually I don't know if that checks signatures or not
<ifreund>
also I've never felt the need to use it
<kameliya[m]>
i have dipped into it from time to time, with fun results :3
<zags>
ifreund: i kinda wanna check it out to give nicer compile errors given the anytype discussion above
<zags>
like, i want if (!@hasDecl(s, fn lambda([]const u8) u32)) @compileError("nice explanation")
<zags>
:)
<ifreund>
I guess I've managed to avoid using anytype well enough so far that I haven't felt the need
<zags>
yeah this isn't common for sure
<ifreund>
the main thing I use it for is passing around std.io.Writer/Readers
<ifreund>
and I find the paramter names clear enough for that as they are well-known types
ur5us_ has joined #zig
<ifreund>
I kinda feel like zig just needs to make structural typing explict instead of implict through the "try it and see if it errors" approach of anytype
<zags>
agreed
<zags>
const type = @typeInfo(@TypeOf(...))
<zags>
is there a utility to dump the type structure?
<ifreund>
std.debug.print("{}\n", .{foo}); can print structs
<zags>
The input is actually a struct with a few fields
<ifreund>
you don't need the @TypeOf() then
<ifreund>
@TypeOf(struct{}) is type
<zags>
yeah, tried that, got some compile error
<ifreund>
you want @typeInfo(sturct{}) though
<zags>
note that the input here is from an anytype
<zags>
passed as a param
<kameliya[m]>
what was the compile error?
<ifreund>
you do need the @TypeOf() then
<ifreund>
how are you calling your function?
<zags>
kameliya[m]: expected type 'i32', found '*const comptime_int'
<zags>
when I try to print it
<zags>
@typeInfo(x), where x is an anytype parameter
<ifreund>
I'm guessing that you are passing a type as your anytype param instead of a value
<zags>
then I try to print that
<ifreund>
s/value/struct value/
<ifreund>
(types are values at comptime)
<zags>
ifreund: well, I pass a struct value, I know that because the function works, it accesses a field
<ifreund>
not sure what you're doing wrong then, would probably need to see the code to be of much more use
<zags>
i'm trying to print the typeinfo struct to get a clue of what it contains
<zags>
that's compile time so doesn't seem like print should work
<zags>
tried compileLog without luck
<ifreund>
@typeInfo() returns a normal struct
<ifreund>
no reason you can't print that at runtime
<kameliya[m]>
yep, this is the compile error I get if I try to print a typeInfo of a struct:
<kameliya[m]>
/Users/kameliya/Code/zig/build-native/lib/zig/std/fmt.zig:540:17: error: values of type 'std.builtin.StructField' must be comptime known, but index value is runtime known
<ifreund>
hmm
<zags>
right, i'm doing compile time reflection here
<kameliya[m]>
looks like there might be a small bug, not sure
<kameliya[m]>
this tries to assign a pointer (`*i32`) to a value (`i32`) and fails.
<kameliya[m]>
but it only fails when you try to instantiate the type.
<zags>
yes, removing that and I get
<zags>
values of type 'std.builtin.Declaration' must be comptime known, but index value is runtime known
<kameliya[m]>
that's why you're sometimes seeing the `*const comptime_int` error
<kameliya[m]>
yep
<zags>
same as you
<kameliya[m]>
that's where we got to above, it's a bug
<zags>
alright
<kameliya[m]>
worth noting closures won't generally Just Work unless you're somehow doing work to save the frame that the closed-over stuff points to.
<zags>
yeah, this wasn't supposed to survive the calling call-frame
<zags>
just playing around
<kameliya[m]>
ya.
<zags>
but in that example, what's the most succinct way to instantiate the struct directly to the closure variable?
<kameliya[m]>
`throw another {}` in
<kameliya[m]>
err
<kameliya[m]>
throw another `{}` in
<kameliya[m]>
`const closure = struct{ ... }{}`
<zags>
i'm amazed my original code worked then, didn't have it
<kameliya[m]>
`anytype`!
<zags>
so where does the instance actually materialize?
<kameliya[m]>
zags: fwiw, here's reworking it into something that kinda works: https://0x0.st/-iG4.txt
<zags>
seems like footgun stuff
<kameliya[m]>
the type itself remains anonymous, but you can get it back, e.g. with `@typeOf(closure)`
<kameliya[m]>
(and it'll be the exact same type, i.e.)
<zags>
should I get a big fat warning from "const my_capture: i32 = &outsidevalue;" ?
<zags>
in the original code
<kameliya[m]>
yes, but only if you try to instantiate it.
<kameliya[m]>
if you don't, it doesn't get semantically analysed.
<zags>
but, but, but... it worked (because of anytype?) :D
<kameliya[m]>
you can write all sorts of nonsense and as long as it doesn't get analysed, the compiler won't care. this is how you can do comptime stuff.
<kameliya[m]>
nah, it just didn't get seen.
<zags>
it actually gave the correct runtime value
<zags>
let me show you
<kameliya[m]>
sure!
<kameliya[m]>
in general if you've written `const x: i32 = &abc` and it still compiles, then i guarantee you the line just didn't get seen. you can't set `i32` to a pointer of anything.
<kameliya[m]>
it's worth nothing `const x: i32 = 123;` doesn't make a struct field, too.
<zags>
kameliya[m]: my original delimited fields with semicolon, you used comma, what's the eli5 here? :D
<kameliya[m]>
`const a: b = c;` is a regular statement; it doesn't belong to the struct per se. `struct { a: u32, b: i32, }` -- these are struct fields.
cole-h has quit [Quit: Goodbye]
<zags>
hm
cole-h has joined #zig
<kameliya[m]>
in `struct { ... }`, the `{}` are opening a new scope. you can say `const x = 1 + 2;` in that scope and refer to `x` later, and it'll work. you can't refer to `x` outside the scope. but the same would be true of just regular `{}` without struct.
<kameliya[m]>
./test5.zig:6:47: error: no member named 'x' in struct 'S'
<kameliya[m]>
change x to y on the print line and it works
<zags>
so those statements are executed on instantiation?
<zags>
before field initialization?
<mikdusan>
kameliya[m]: change to S.x ?
<kameliya[m]>
(oh, but you can say `S.x`)
<kameliya[m]>
they're decls in the scope of the struct, rather than fields of the struct. does that make any more sense?
<zags>
order of initialization is important. Order of appearance, decl then field, or?
<kameliya[m]>
fields are initialised when you actually instantiate an instance of the struct. decls are probably initialised when the struct itself is analysed? (i.e. comptime) i'm not too sure on the details.