ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<MajorLag_>
Interesting, but doesn't @memberXXX only work on enum types? And that meta-field takes up space in the struct at runtime?
<andrewrk>
@memberXXX works on structs, enums, and unions
cenomla has joined #zig
<andrewrk>
except I think @memberType does not work on enums
<MajorLag_>
huh, documentation made me think otherwise
<andrewrk>
I'll update it
<andrewrk>
oh, yeah. it used to. I need to add docs to struct and union sections
<MajorLag_>
given that the field name is comptime accessible, one could just encode the serialization information in the field name itself. Or, use const members to tell you how to serialize each field. Yeah...
<andrewrk>
zig has a concept of types that have 0 bits. this includes void and structs with all fields 0 bits (or no fields)
<andrewrk>
types that have 0 bits do not generate any runtime code
<MajorLag_>
oh right, so your way works fine then.
<andrewrk>
it might work better for a library, that wants to provide a type, and then only do something with fields that are preceeded by a field of that type
<andrewrk>
you could even have a function that accepted comptime parameters and returned a type, so it would be something like `_: serialize(endian.Big)`
<MajorLag_>
I was thinking it would be useful for netcode. Often the way you represent a struct in memory is not the way you want it on the wire, and having the ability to write a struct once and produce an on-wire version automatically, as well as functions to transform between the two, would remove some tedium.
<andrewrk>
yeah. I should make a proof of concept json parser/serializer
<MajorLag_>
I'm going to make a note to play around with this later, see what can be accomplished even without @field.
<andrewrk>
oh yeah, forgot you could use offsetof like that
<andrewrk>
cool
<andrewrk>
I need to add support for `_` as a struct field
<andrewrk>
I crashed the compiler by adding a string field
<andrewrk>
oh, I know this bug. right now we don't support a var or const changing types inside a comptime loop
<andrewrk>
but it works if it's just an expression
davr0s has quit [Ping timeout: 256 seconds]
<MajorLag_>
Next step: make a function that traverses a type hierarchy and prints out all members and values of a struct. That'll come in handy for debugging.
<andrewrk>
yeah. and then integrate it with std.fmt.format
Topa has joined #zig
Topa has quit [Ping timeout: 252 seconds]
<MajorLag_>
is there a reference for the members of type?
Topa has joined #zig
jfo has joined #zig
<andrewrk>
MajorLag_, I believe that is a documentation TODO
<tjpalmer>
Read a bit more on the conversations from yesterday, including on various feature discussions.
<tjpalmer>
Concerning Rust, this is on their 2018 roadmap: "Continuing to improve compile times. By the end of the year, recompilations on large crates should be around 30s."
<tjpalmer>
Recompilations.
<tjpalmer>
Anyway, I personally think that Zig feature set is at a good minimum viable product, by which I mean I think it's an order of magnitude better than C.
zesterer has quit [Quit: zesterer]
<tjpalmer>
Other than ironing out pain points, I'd recommend not iterating much on the existing feature set. I personally think pushing toward a stable released 1.0 is more important.
<tjpalmer>
I think it's a good enough foundation that it can be iterated on later. Just my two cents.
<tjpalmer>
And pain points will be found best by writing Zig code, such as with the current work on the self-hosted compiler. Again, anyway, just my two cents.
Topa has joined #zig
Topa has quit [Ping timeout: 256 seconds]
<tjpalmer>
Anyway, my point on Rust was explaining one reason why my concerns aren't anywhere inside their roadmap or planned eventual capabilities at all. When I found Zig, I was looking around because I was unhappy with Rust. (Speed and lifetimes, mostly.)
tjpalmer has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag_>
andrewk, ran into a few issues. 1: how do I escape "{" in a format string? 2: []const u8 seems to be TypeId == Struct and I haven't figured a way to detect that it's a slice.
<MajorLag_>
I feel like slice is a special enough struct to get its own TypeId.
<MajorLag_>
Or maybe TypeId should be a flags enum, so it could be struct and array? I don't know.
Topa has joined #zig
Topa has quit [Ping timeout: 246 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
Topa has joined #zig
Topa has quit [Ping timeout: 240 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
Topa has joined #zig
Topa has quit [Ping timeout: 240 seconds]
jfo has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
Hejsil has joined #zig
jfo has joined #zig
jfo has quit [Ping timeout: 246 seconds]
jfo has joined #zig
jfo has quit [Quit: WeeChat 1.9.1]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
arBmind has joined #zig
davr0s has joined #zig
Topa has joined #zig
Topa has quit [Ping timeout: 276 seconds]
cenomla has quit [Quit: cenomla]
Topa has joined #zig
Topa has quit [Ping timeout: 240 seconds]
Topa has joined #zig
Topa has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag_>
worked out how to get a raw '{' in a format string. was that documented anywhere?
arBmind has quit [Ping timeout: 240 seconds]
arBmind has joined #zig
arBmind has quit [Ping timeout: 276 seconds]
davr0s has joined #zig
arBmind has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<MajorLag_>
andrewrk, think I've run into some bugs re: comptime vars and 'type'. Can't reassign a comptime var of type 'type' (attempt to dereference non-pointer type), and using a separate var crashes the compiler, I think this has to do with the use of 'undefined' in this context.
hoppetosse has joined #zig
<hoppetosse>
andrewrk: Would it be possible for 'break expression' automatically break the value into the current block?
<hoppetosse>
equivalent to something like 'break :this expr'
<hoppetosse>
(I know in this case you can leave the braces out since they're single expressions, but in the more general case)
zesterer has joined #zig
Topa has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
arBmind has quit [Quit: Leaving.]
hoppetosse has quit [Ping timeout: 260 seconds]
<andrewrk>
tjpalmer, I agree that pushing toward a stable 1.0 is important. there are a few high level things I want to get started first. 1. error sets (almost done) 2. concurrency/coroutines 3. some various minor language stuff that would be better to do before 1.0
<andrewrk>
MajorLag_, `{{` and `}}` for literal curlies. nope it's not documented. when we get that auto doc generator going it's going to be wonderful
<andrewrk>
I agree the TypeId situation for slices is problematic, would you mind opening an issue?
<andrewrk>
hoppetosse, the only reason break can't do that is if you were in a loop it would be counterintuitive that it is not breaking from the loop
davr0s has joined #zig
<MajorLag_>
andrewrk, will do. For now I'm checking the typeName[0] for '[' to tell the difference. Ick.
<andrewrk>
yikes
<andrewrk>
at least it's a compile-time hack and not a runtime one, so you'd probably get an error if it didn't work
<andrewrk>
it's generally better to avoid non-tail-call recursion
<andrewrk>
and use an explicit stack
<andrewrk>
I think zig's coroutines, when they exist, might help solve recursion woes
<MajorLag_>
yeah, I can probably refactor this differently. recursion was just the easy way. Interestingly only seems to happen using debug.warn to format and print ints.
jfo has joined #zig
<andrewrk>
hmm.
<andrewrk>
maybe because that involves several more stack frames?
<jfo>
I wonder if there is an argument for moving the block vars into the braces and using that syntax for anonymous function declarations as well eg for (exes) |x| {...} becomes for (exes) {|x| ...}, and fn(x) {...} could also be written as {|x| ...}
<MajorLag_>
or it could be something else. if I replace the variable with a constant it should still have to format it the same way, but then it doesn't crash.
<andrewrk>
jfo, what would that argument be?
<jfo>
it's not a strong argument but it feels more natural to me to contain that var in the block like that, mostly from ruby back in the day using {|var| ... } for blocks.
<andrewrk>
so it's a syntactical argument
dd3 has joined #zig
<jfo>
yes, also just related to the discussion about anon fns
<jfo>
but fn() {} is totally reasonable of course
<andrewrk>
anon functions will look the same as a function definition, but with no name
jfo has quit [Ping timeout: 256 seconds]
jfo has joined #zig
<jfo>
where did the || {} syntax come from?
Hejsil has joined #zig
<MajorLag_>
andrewrk: comptime var RootType = @typeOf(root); if(... RootType is a ptr ...) { RootType = RootType.Child; } => error: attempt to dereference non pointer type 'type'. Is this a bug or am I not understanding something about comptime?
<MajorLag_>
I suspect the latter. The check is happening at run time where 'type' isn't a thing i can work with like this?
<MajorLag_>
In which case... I have to rethink how this works.
jfo has quit [Ping timeout: 256 seconds]
<andrewrk>
MajorLag_, hm I think I need to see more code to understand
zesterer has quit [Quit: zesterer]
jfo has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zesterer has joined #zig
zesterer has quit [Quit: zesterer]
zesterer has joined #zig
zesterer has quit [Client Quit]
zesterer has joined #zig
<MajorLag_>
andrewrk, I'll probably be sending you something shortly. Want to see if life is any easier if I heap allocate the string, but my suspicion is that isn't the real problem.
jfo has quit [Ping timeout: 252 seconds]
jfo has joined #zig
<MajorLag_>
Something else is going on here. It's as if format isn't cleaning up after itself or something. I don't know.
jfo has quit [Read error: Connection reset by peer]
<MajorLag_>
Oh you know what, maybe this is a pointer alignment issue.
<andrewrk>
let me see if this is an easy fix
<MajorLag_>
the layout of the struct seems relevant, but I'm not sure how. If I don't change it and also don't print certain values it works.
<zesterer>
Just thought you'd like to know... I installed zig using the AUR (i.e: building from source) and what I presume is part of the build process managed to use 1.2G of memory before I killed it.
<andrewrk>
zesterer, this is prior to running `zig build` or after?
<zesterer>
andrewrk: I don't know. The AUR package script does everything automatically.
<zesterer>
andrewrk: I have no idea. "yaourt -S zig-git" was the only command I ran. Yaourt, the pkg script, and Zig's build system do the rest"
<andrewrk>
it requires 2 GB I believe
<andrewrk>
it's planned to support a memory cap in the self hosted compiler, but we're not there yet
<zesterer>
Hmmm :\ Might be best to add some kind of warning. My computer froze for about 10 minutes
<andrewrk>
I have a whole rant about that
<andrewrk>
default linux memory management has overcommit on
<andrewrk>
it lies about how much memory is available on the system
<andrewrk>
and then when it runs out it shits its pants
davr0s has joined #zig
<andrewrk>
zesterer, you should be able to run some install command that skips the check() step
<andrewrk>
I don't use arch, but I'm sure it exists
<zesterer>
I can just alter the pkg script.
<zesterer>
The maintainers should probably edit it though
<andrewrk>
I mean it's not wrong. it just requires 2GBish of RAM
jfo has joined #zig
arBmind has joined #zig
jfo has quit [Ping timeout: 252 seconds]
<andrewrk>
MajorLag_, it's not a trivial bug, I'll file an issue for it later
<MajorLag_>
But it is a bug? I can stop pulling my hair out trying to understand it?
<andrewrk>
MajorLag_, it's for sure a bug
<andrewrk>
I mean the code you sent me caused an assertion failure
<andrewrk>
all assertion failures are bugs
<MajorLag_>
huh, it just crashed for me. Maybe it's time to make sure I'm on current master again.
<andrewrk>
you're on windows? I'm guessing you did a release build
<andrewrk>
assertions are off in release builds
<andrewrk>
I was unable to get a release llvm + debug zig on windows, it seems you have to choose one or the other
<MajorLag_>
I'm on windows, but it was a test build
<andrewrk>
and debug llvm + debug zig is extremely slow. it works, but it's unusably slow
<MajorLag_>
does "zig test" build in release or something?
<andrewrk>
I mean a release/debug build of zig compiler itself
<andrewrk>
it has to do with -DCMAKE_BUILD_TYPE
<MajorLag_>
ah, gotcha
<andrewrk>
the wiki instructions for building zig on windows are for the release build
hoppetosse has joined #zig
<hoppetosse>
andrewrk: just saw the latest issue in the tracker, that's exactly what I meant
<andrewrk>
hoppetosse, yeah I don't want to change break's behavior because it would confuse C users
<andrewrk>
it would confuse everybody, really
<hoppetosse>
yeah, that's a good point, I just had no idea what else to call it =P
<MajorLag_>
yeah, I'm not ambitious enough to build zig when there's a perfectly good artifact already built for me
<andrewrk>
MajorLag_, you've been using the appveyor artifacts, yeah?
<andrewrk>
I'm pretty happy with how that's been working out
<MajorLag_>
yep
<MajorLag_>
BTW, I see that I was dereferencing a struct in that code if a struct was a member of another. Changing that behavior seems to have avoided the bug, probably because the compiler was supposed to yell at me about doing that.
<MajorLag_>
dereferencing a struct and then passing it into the recursive function that is.
<andrewrk>
ah
hoppetosse has quit [Ping timeout: 268 seconds]
dd3 has quit [Ping timeout: 256 seconds]
jfo has joined #zig
<andrewrk>
MajorLag_, I plan to modify the rule about structs having to get passed as &const T
<andrewrk>
you'll be able to do something like: fn foo(bar: Bar) {}
<andrewrk>
Bar being a struct, and it acts semantically like a value, but in the generated code it's a pointer (or a value, depending on what's faster)
<andrewrk>
at the callsite, when you pass a struct this way, you're guaranteeing that the data won't change during the lifetime of foo
<andrewrk>
that'll just be a way that you could cause undefined behavior (and maybe we insert a safety check for this)
<andrewrk>
the benefit being that 1. it optimizes better and 2. it gives you more natural semantics
dd3 has joined #zig
<andrewrk>
it lets us put "noalias" on everything passed this way
<benzrf>
ever since i read about the logic behind C's type declaration syntax it's seemed vaguely off-looking to see technically-more-reasonable syntaxes like "foo: &T"
<MajorLag_>
I could see that becoming confusing. I might modify a value and return the struct thinking it's a copy, but it isn't. If the caller didn't expect the original to be modified that's a problem. Personally I'd favor having to be explicit one way or the other.
<andrewrk>
benzrf, I'm not familiar with the logic, can you enlighten me?
<andrewrk>
MajorLag_, modifying parameters is already not allowed
<andrewrk>
that would be a compile error
<MajorLag_>
so how could you cause UB if the compiler won't let you do it?
<benzrf>
andrewrk: oh really?
<benzrf>
well, "int foo" means foo is an int, right?
<benzrf>
so "int *foo" means *foo is an int
<benzrf>
and "int foo[3]" means foo[3] is an int ok well that one doesnt quite work
<andrewrk>
"foo is an error or null or a slice of int"
<andrewrk>
no web page needed to understand this syntax
<benzrf>
but if you know the precedences of expressions, you know the precedences of types
<benzrf>
is *foo[3] derefing foo[3] or indexing *foo? well, that's also whether int *foo[3] is an array of pointers or a pointer to an array
<benzrf>
or int (*x)(char, char) means that... well... *x(char, char) is an int
<benzrf>
i dont, of course, believe that this is more reasonable than what zig does, or what literally any other language does
<andrewrk>
benzrf, I appreciate the explanation, but I must confess I'm not finding it intuitive
<MajorLag_>
andrewrk, another issue I see with having the compiler choose if structs are referenced or copied is if I do @ptrToInt stuff. I might not get what I expect.
<benzrf>
it's just that i've gotten used to parsing c declarations that way, so looking at types in saner low-level languages triggers the same routine in my head, and it looks backwards
<benzrf>
:v
<andrewrk>
MajorLag_, you could cause UB if you had another thread, and modified the value there. that's pretty unlikely. the more common case is that you pass the same value to a function twice. I'll show an example, just a sec
<andrewrk>
benzrf, I see
<andrewrk>
I'm personally happy to retrain habits that have formed out of unfortunate necessity
arBmind has quit [Quit: Leaving.]
<andrewrk>
I know that's not true for everyone
<andrewrk>
I keep conventions that already exist if they are harmless
<benzrf>
well, i didn't mean it as a suggestion for a change :>
<benzrf>
just a vague comment
* andrewrk
nods
<benzrf>
as a connoisseur of type systems, i would never ever want C's bizarre mixing of type and bound name in anything with real types
<benzrf>
once you try to write a C type as its own expression instead of as a declaration, the parsability drops way off
<benzrf>
not that it was great to begin with
<benzrf>
s/instead of as a/instead of as part of a/
<andrewrk>
MajorLag_, the compiler could figure out this one and make it a compile error, because it's pretty obvious that you aliased a mutable pointer with a const pointer, but you could obfuscate this enough so that the compiler couldn't catch it at compile time
<andrewrk>
we could catch it at runtime with a secret field in Bar though
<MajorLag_>
Ok, so how about if I explicitly say fn(foo: &Foo)? Will the compiler always give me a pointer to the struct? If so, I think having the compiler determine when it isn't explicit is probably fine.
<andrewrk>
MajorLag_, in this case, it's a mutable pointer to a struct
<andrewrk>
I'm not sure I understand the question
<andrewrk>
you would only be allowed to pass a mutable pointer to Foo to that arg
<andrewrk>
fn(foo: Foo) would be explicit syntax for "I am passing a struct. The compiler may choose to pass a reference or a value. In case it is a reference, I promise to not modify the contents of the argument I pass for the duration of foo()."
<MajorLag_>
If I'm understanding you correctly, then most of my objections go away. Because if I want to do crazy @ptrToInt stuff then I can explicitly say I need a pointer and the caller has to explicitly give me one.
<andrewrk>
rather "...I promise the contents of the argument I pass will not be modified for the duration of foo"
<MajorLag_>
and if they are, the compiler calls me out on it, or runtime checking does?
<andrewrk>
yes
<andrewrk>
that's the idea
<andrewrk>
and it allows some pretty decent optimization opportunities
Hejsil has quit [Read error: Connection reset by peer]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag_>
Is it just me, or are "result" and "return" just two different ways of saying the same thing in that proposal? The only real difference is that "return" only exists in special blocks called functions that get call/ret, calling convention, and stack manipulation wrapped around them.
<MajorLag_>
Since we already know a function is a function by virtue of how it is declared and called, result seems like a redundant keyword to me.
Topa has quit [Quit: WeeChat 2.0.1]
<andrewrk>
MajorLag_, according to the proposal, `result` and `return` would have the same behavior in the outermost block of a function
<andrewrk>
`result` would be equivalent to `break :x` if the current block were labeled `x`
<benzrf>
so andrewrk, if you're already embracing "we have a type of types and compile-time evaluation", why not go full dependent typing?
<benzrf>
;)
<andrewrk>
I'll give you a serious answer to that question
<benzrf>
:O
<andrewrk>
because there is no coherent proposal to add dependent typing which adheres to zig's goals, which, as a reminder, one of them is a low burden of reasoning about the language and type system when reading code
<MajorLag_>
andrewrk, sure but imagine if that inner block were a function call instead of a block, it would use return. the only difference is that it isn't a function.
<benzrf>
uhhh
<benzrf>
then why is your type system turing complete :P
<andrewrk>
MajorLag_, I'm guessing you're right, but I'm not following along with your example
<benzrf>
wait hold on
<benzrf>
wtf, you already HAVE dependent typing but only for arguments of type type
<benzrf>
o.O
<MajorLag_>
I'll try and give a more coherent argument in the thread later, I will be busy for a few hours.
<andrewrk>
MajorLag_, fwiw I'm leaning towards rejecting the proposal, to keep the language smaller
<benzrf>
oh wait
<andrewrk>
benzrf, "why not implement dependent types" is an argument from language design. that's not how zig works. zig is use case driven. "I have this use case. The current language fails to handle the use case in an adequate way. Therefore some change needs to happen which fits within the goals and solves the use case"
<andrewrk>
this is the reasoning that zig uses
<benzrf>
hold on, is fn notation allowed in a test block
<benzrf>
im fucking around trying some stuff and i get weird parse errors if i move something from outside the test block to inside it
<andrewrk>
currently you cannot create a function inside a function
<andrewrk>
I think you can work around it by making a struct inside a function and putting a function inside that
<andrewrk>
a test block is a function body
<benzrf>
ok wtf you actually are already dependently typed
<benzrf>
starting to think maybe type-value unification is a questionable idea outside of pure languages if you wanna be at all principled about it >.>
<andrewrk>
benzrf, the interpreter and the analysis is the same thing
<benzrf>
oh
<benzrf>
huh
<andrewrk>
analysis *is* interpretation
<benzrf>
hmmmmmm
<benzrf>
wait do you mean that in a broad sense or as an implementation detail of zig
<andrewrk>
the latter
<benzrf>
oh hah
<andrewrk>
but in the broad sense, yeah, it's called "abstract interpretation"
<benzrf>
hmmmm
<benzrf>
hold on
<benzrf>
does that subsume interpretation where you treat variables as opaque & interpret as far as u can based on inferrable knowledge without having a specific value
<andrewrk>
zig doesn't do that yet but it has plans to
<benzrf>
interesting
<andrewrk>
it does, essentially, 1 iteration of a lattice
<benzrf>
lattice?
<andrewrk>
a lattice is the structure you use for abstract interpretation as you described it
<benzrf>
i assumed it was some separate programming thing
<benzrf>
hmm....
<benzrf>
dude, you could totally do some simple computational type theory tricks here
<benzrf>
hmmm
<MajorLag_>
before I head out: var x = i32(1); x will be a mutable i32 with a value of 1. var x = []i32{1}; x will be a length 1 array of muatble i32 with first value set to 1. var x = ([]i32{1})[0..]; x will be a slice of const i32. Why not mutable?
<andrewrk>
MajorLag_, you can reassign x. so x is mutable in that way. but an array literal - like string literals - are const if you don't initialize a var with them
<andrewrk>
in fact, all literals are const, if you don't provide mutable storage for them
<MajorLag_>
I ask only because it makes initializing a slice more painful than I think it should be.
<andrewrk>
a slice is a reference. so you also have to tell zig where you want the data to go
<MajorLag_>
yeah, I suppose. Usually when I'm doing this it never leaves scope, so the stack is fine, but I can see how that'd be a problem if I tried to return it.
<benzrf>
i just wanted to try 17:58 <benzrf> dude, you could totally do some simple computational type theory tricks here
<benzrf>
this case being, defining types whose inhabitants are based on the validity of a proposition w/o themselves carrying a proof
<andrewrk>
MajorLag_, this is https://github.com/zig-lang/zig/issues/287 but when you call a function with a struct/array as return value, it passes a pointer to where the return value can go, and so the function directly initializes the memory
<andrewrk>
no hidden copy
<andrewrk>
once this issue is complete, there will be no hidden copies, and only using `=` can cause a memcpy
<aiwakura>
people talking about zig on #osdev
<aiwakura>
it's happening
<benzrf>
O:
<aiwakura>
we are taking over
<andrewrk>
all your codebase are belong to us
<benzrf>
andrewrk: so why exactly does that loop reassigning ty error out
<andrewrk>
idk yet, it might be a new bug
<benzrf>
oh do i need to put it in a "comptime" block