ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has joined #zig
jfo has quit [Ping timeout: 252 seconds]
hasen_judy has joined #zig
skyfex has quit [Ping timeout: 260 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
jfo has joined #zig
lorde_kumamon[m] has joined #zig
<lorde_kumamon[m]>
So, is IRC still the main place for discussion?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jfo has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
<andrewrk>
lorde_kumamon[m], yes
<lorde_kumamon[m]>
Great
hasen_judy has quit [Remote host closed the connection]
hasen_judy has joined #zig
<lorde_kumamon[m]>
I was a happy Rust user, but I'm going back to C++. I don't want anything with that community ever again. So I'm lurking for alternatives that might become ready to replace C++.
<lorde_kumamon[m]>
A friend suggested Zig, so I saw there is an IRC room and I came here, but I'm still reading the site
<andrewrk>
zig is young compared to rust
<andrewrk>
but the language is much simpler, so we can move fast
<lorde_kumamon[m]>
I'm curious about thing. That's why I joined the IRC channel. I won't have this answer lurking in the project pages
<lorde_kumamon[m]>
I'm okay working with people from different political views. Projects should always stay technical (lile Torvalds attitude: show me the code)
<lorde_kumamon[m]>
But Rust community is a cancer that I can no longer bear
<lorde_kumamon[m]>
It's everywhere from the today's noob to all leadership team
hasen_judy has quit [Ping timeout: 276 seconds]
<andrewrk>
lorde_kumamon[m], what you are talking about is offtopic here
<lorde_kumamon[m]>
And the problem there is: they mix politics with technical debate
<lorde_kumamon[m]>
andrewrk: great. This already answer my question. Thanks very much.
<GitHub68>
zig/master 46aa416 Andrew Kelley: std.os and std.io API update...
<GitHub68>
zig/master 8c31eaf Andrew Kelley: std zig tokenizer: don't require 3 newlines at the end of the source
<MajorLag_>
andrewrk: I think it would be useful to be able to return an instance of a struct that's defined within the function returning it. Compiler doesn't seem to like this. Am I missing something or is it just not a thing?
<andrewrk>
MajorLag_, what did you put for the return type?
<MajorLag_>
I actually forget what I was really trying to do with this this morning. I was trying to see how terse a closure implementation I could make in Zig I think and this came up.
<MajorLag_>
It was an exercise, I actually don't find much use for closures.
Jezza has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
<andrewrk>
MajorLag_, that seems like a pretty reasonable error - trying to access a variable that is out of scope
<andrewrk>
you'd need support for inferred return type to do that
davr0s has joined #zig
davr0s has quit [Client Quit]
<MajorLag_>
I'm not chomping at the bit for it or anything, it was just something that came up. That and either tuples or a way to comptime generate structs with variable numbers of fields. None of this is anything I actually really want mind you.
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 265 seconds]
davr0s has joined #zig
hasen_judy has joined #zig
benzrf has left #zig ["WeeChat 2.0.1"]
hasen_judy has quit [Ping timeout: 255 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 265 seconds]
<MajorLag_>
How does this proposed pointer syntax work with the null? var v: []null T ?
<andrewrk>
MajorLag_, yeah
<andrewrk>
it's extra information in the slice type that guarantees a null at v[v.len]
<MajorLag_>
Ok, and the new array syntax is for stack allocated fixed length arrays. So [] always means it's a pointer. Right?
<andrewrk>
not necessarily stack allocated. global storage too
<andrewrk>
but yes [] always means it's a pointer, that's the idea
jfo has joined #zig
<MajorLag_>
it feels a little weird, but it makes sense.
jfo has quit [Ping timeout: 255 seconds]
<MajorLag_>
?^?[*]null u8 for C's **char...
<andrewrk>
MajorLag_, you mean like the argv array that gets passed to main?
<andrewrk>
it would be: [*]null [*]null u8
<MajorLag_>
there are other contexts for **char, like changing the actively displayed string based on what you're mousing over or whatever. Don't get me wrong, the fact that there are multiple meanings of **char is good evidence why this is better.
<andrewrk>
ah I see
<andrewrk>
oh yeah I'm missing the nullability too, in the argv example: ?[*]null ?[*]null u8
<vegard>
so in the C equivalent, if you just did: const int *xptr = &x; then this would generate a relocation to x where xptr is defined, right?
<vegard>
and the question is, when you replace that &x by a function call (which is evaluated at compile time), and especially when you combine that with cross-compilation, does it still manage to output a relocation?
<andrewrk>
I found a related bug when looking into this, but apart from this bug (which I'm about to fix) the answer is yes it all works, even when cross compiling, because llvm supports that
<vegard>
I'd be curious to see the objdump -Dr for the zig-generated object file
<vegard>
and I still don't really understand how it would work when x_ptr is initialised through a function call :-D but if it does, then that's wonderful.
<andrewrk>
notably, if it's a pointer, it knows information about its parent, such as, am I pointing to the 3rd array item of something, or the 4th field of a struct
<andrewrk>
vegard, I have the same bug if you do `export var x_ptr = &x;`
<andrewrk>
so the compile time stuff is working fine, this is something else
<vegard>
ah, hm
<vegard>
I think maybe my problem is that I'm trying to actually JIT-compile everything that gets executed at compile time
jfo has joined #zig
<vegard>
since that doesn't preserve any of that "parent information", it only works on the raw byte values (as compiled code would do)
<andrewrk>
ah I see
<andrewrk>
yes, zig compile time execution is very much interpreted
<andrewrk>
and safe - you can't crash the compiler with it
<andrewrk>
well, in theory you can't. there are defintely bugs right now :)
<vegard>
so if you had a struct type with a pointer member, is the size of that struct different at compile time from what gets put into the binary?
<andrewrk>
the pointer size is known at compile time
<andrewrk>
I don't think I understand the question
<vegard>
I mean if you had (using C syntax) struct foo { int *p; }; struct foo a = ...; struct foo b = a; then that would generate a copy of a and store it in b. that copy would not be a straight memcpy, but it would also have to copy that extra "parent information"
<vegard>
so the actual size of the struct is larger than just the raw byte values
<andrewrk>
you're thinking of it in terms of JIT still
<vegard>
probably :-P
<andrewrk>
in zig we have this extra information but we preserve the semantics of the zig code as if the struct were how it would act at runtime
<andrewrk>
there is no actual struct at compile time
<vegard>
ok, I see
<andrewrk>
it's this ConstExprVal thing. and we use it to implement every operation that you can do with a struct in zig code
<vegard>
there is no operator overloading in zig, right?
<andrewrk>
correct
<vegard>
so if you allocated an N-size array of int pointers at compile time, you would actually have to allocate a lot more memory than just N * sizeof(int), right?
<andrewrk>
vegard, one thing that I think is unique to zig's compile time execution is how printf works
<andrewrk>
I'd be curious how you plan to do it in v
<andrewrk>
that's correct, it would implement N * sizeof(ConstExprVal)
<andrewrk>
s/implement/allocate/
<andrewrk>
we can potentially do an optimziation where we try to only allocate N * sizeof(int), but if you for example take a pointer to one of the elements, we'd have to expand this out
<andrewrk>
we do this optimization if all the elements are the value undefined
<vegard>
yeah, as I said I don't really have a solution that works myself! so maybe this extra information and interpreting it is the solution
<vegard>
I just had this feeling that if something can be done efficiently at run-time, then it should be possible to do it equally efficiently at compile time.
<vegard>
and I mean, it is, clearly. but for cross-compilation especially you would need some shuffling/marshalling of the data when you want to output the object file.
<andrewrk>
for one off things, interpreting is often faster
<andrewrk>
JIT only starts to pay off if you have some loops
<vegard>
yeah but what if you program needs the first 10k prime numbers? well, you would probably cache it.
<vegard>
it still feels like something you should be able to do without having to invoke the compiler twice.
<andrewrk>
yeah you just cache it, same as how you will cache analysis of functions
<andrewrk>
zig caches all compile time function calls
<andrewrk>
it's part of the semantics, so that functions which return types, can return the same type
hasen_judy has joined #zig
jfo has quit [Ping timeout: 240 seconds]
<MajorLag_>
andrewrk: re: pointer reform and the ^ symbol. Would you be willing to consider alternatives for a dereference operator? If so, you could take back * for "pointer to a single thing".
<MajorLag_>
and it would have nice symetry: *T, [*]T, [*]null T
<andrewrk>
MajorLag_, that's pretty good. what would you propose for the deref operator?
hasen_judy has quit [Ping timeout: 265 seconds]
<andrewrk>
you know what
<andrewrk>
we could allow implicitly dereferencing a pointer
<andrewrk>
given that it only points to 1 thing
<andrewrk>
that's a separate issue
<andrewrk>
we still need a deref operator
<MajorLag_>
Not sure you'll like my suggestion, but ".". accessing a struct field in Zig is struct.field regardless of "struct" being a pointer or not, so "." already sorta dereferences. As a postfix operator it also has the potential to be clearer: (*a).b.c => a..b.c //where a is &&struct; a*b**c //where c is &i32 => a*b*c.; of course, then you'll need to change the slice range operator, conveniently -> is available: var s = array[x->y];
<andrewrk>
interesting
<andrewrk>
return a.;
<andrewrk>
it's a little subtle
<MajorLag_>
regardless of what a new deref operator would be, I do like * for pointers. everyone is used to them, they don't have the keyboard issues of ^ and it's got nice consistency with the new block pointers
<MajorLag_>
ayeah, there is that
Hejsil has joined #zig
<MajorLag_>
I thought of backtick, but it has similar keyboard issues to ^ from what I can tell and it is also subtle.
<andrewrk>
I do like the * idea, i'll think of some ideas for deref
<andrewrk>
what about `[0]` postfix
<MajorLag_>
it's very C. My thought would be that it makes whatever you're dereferencing look like it's a block.
<andrewrk>
generally you should not be able to click somewhere, insert a single space, and then have the code still compile successfully but have different results
<MajorLag_>
yeah, I'd agree with that
<MajorLag_>
Ok here's a though, if Zig implicitly dereferences a single poiner (&i32 vs &&i32), maybe ^ isn't a big deal to use for postfix deref?
<MajorLag_>
No, wait, Zig has ^=
jfo has joined #zig
<MajorLag_>
On that note, if zig implicitly derefs a single pointer, then maybe mandating the use of ()s when derefing isn't so bad. (a*) = 1; but only if a is **i32. if a is *i32 then: a = 1;
<MajorLag_>
Not sure it's a great idea to obscure pointers that way, but it's done for structs already.
<MajorLag_>
problem with implicit deref is, if a and b are both &i32: a = b; is ambiguous.
<MajorLag_>
unless of course you want to introduce a new operator for "change where this pointer points", which I'd rather not.
<MajorLag_>
although: a->b; a->&c; ...
<andrewrk>
MajorLag_, I don't think we would make a = 1 work when a is a pointer, but maybe we would allow it if passing to a parameter that wants a i32 you could pass a *i32
<GitHub24>
zig/master f2d6016 Andrew Kelley: fix exported variable not named in the object file...
Hejsil has quit [Read error: Connection reset by peer]
<MajorLag_>
a> = 1; a>.b.c; a*b*c>; double deref would have to be (a>)>. Don't think it conflicts with logic, var x = a>b; would be invalid if interpreted as (a>)b. I dunno, it's a tough problem.
<andrewrk>
man. people would complain about that so hard
<MajorLag_>
people complain about anything, but yeah, we can probably do better.
<andrewrk>
just throwing some more ideas out there
<andrewrk>
[0] for block types like [*]
<andrewrk>
.0 for *
<andrewrk>
postfix [x] is definitely the correct way to deref block pointers
<andrewrk>
I'm warming up to . postfix too
<andrewrk>
I'm fine with [start:end] being the slice syntax
<MajorLag_>
[0]T makes sense enough I think. A zero length array otherwise being meaningless. When you say .0 for *, we've thrown around so many variations I'm not sure what you're referring to. .0 as a deref? Seems strange.
<andrewrk>
yeah I meant as a deref
<andrewrk>
we already have foo[x] deref for block style pointers, we'll just keep that, and there won't be anything else you can do
<andrewrk>
so all we need is a way to deref only-1-thing pointers
<MajorLag_>
well, thinking about it, it kinda makes sense. If we pretend "a" is a struct, "a.0" is a field representing "a" itself, though then I'm tempted to be able to access any field of a using a numeral "a.1" for the first, etc. Which is intriguing, but probably a bad idea.
<andrewrk>
the problem with `.` postfix is that it's ambiguous with `.` as a field access
<andrewrk>
...or is it?
<MajorLag_>
how so?
<andrewrk>
never mind, it's fine
<andrewrk>
I like `.` postfix
<andrewrk>
let me see if thejoshwolfe approves
<andrewrk>
we have to figure out what to do with the ... operator in switches
<MajorLag_>
-> looks a bit too much like => maybe. could use ":"?
<andrewrk>
problem is that, with slicing, [start:end_exclusive] but with switches it's start...end_inclusive
<andrewrk>
which, there's an open question of do we support the other operator in either case?
<andrewrk>
I think I don't want there to be the other option for slicing
<andrewrk>
actually I think status quo is fine - slicing is exclusive, switch is inclusive. But they should be different operators
<MajorLag_>
"::" could be inclusive, but then I'd expect to be able to use them interchangeably. Also it's a somewhat subtle difference that could introduce errors due to typo.
<andrewrk>
I think *foo could still work
<andrewrk>
if foo is of type `type` then it makes a pointer type. otherwise it's deref
<andrewrk>
hmm no this is #588 again.
<MajorLag_>
comptime var x = *i32; comptime var y = *x; Did I get **i32 or i32?
<andrewrk>
that would be **i32, no problem. but we would have the `*b = f32;` problem from #588
<andrewrk>
I don't think we're going to support the deref on a pointer type
<andrewrk>
e.g. right now in status quo zig there is no such thing as *&i32
<andrewrk>
I think!
<MajorLag_>
there's type.Child anyway isn't there? or am I misremembering?
<andrewrk>
error: attempt to dereference non-pointer type 'type'
<andrewrk>
whew
<andrewrk>
yeah that's right
arBmind has quit [Quit: Leaving.]
<andrewrk>
I want to work on a fun issue for the rest of the day
<andrewrk>
I've been slogging through Important Design Decisions for a few weeks now
<andrewrk>
maybe coroutines :)
Jezza has quit [Ping timeout: 264 seconds]
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 276 seconds]
hasen_judy has joined #zig
cenomla has joined #zig
jfo has quit [Read error: Connection reset by peer]