ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
wink_ has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tridactyla has joined #zig
tridactyla has quit [Remote host closed the connection]
tridactyla has joined #zig
_whitelogger has joined #zig
Shankar has joined #zig
Shankar has quit [Quit: Leaving]
darithorn has quit []
davr0s has joined #zig
return0e has joined #zig
porky11 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
davr0s has joined #zig
_whitelogger has joined #zig
_whitelogger has quit [Excess Flood]
_whitelogger has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
tdc has quit [Ping timeout: 245 seconds]
tdc 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…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
m4ge123 has quit [Ping timeout: 252 seconds]
allochi has joined #zig
Hejsil has joined #zig
<Hejsil>
Hmmm. For tuples to replace varargs, the have to be able to contain both runtime and comptime values at the same time.
<Hejsil>
warn("{} {}", .{ 1, q }); Here, 1 is a comptime_int (comptime only type) and q is some runtime variable (runtime only)
<Hejsil>
This is the only problem I see with this proposal
<Hejsil>
Is there a reason you can't inline a runtime known array?
<andrewrk>
iterating over a "runtime" tuple would work because the tuple's length and types are known at compile time- it would be like iterating over the fields of a struct
<Hejsil>
All the information for inlining is there
<Hejsil>
So is an arrays
<Hejsil>
an array is [2]u8 == tuple.{u8,u8}
<andrewrk>
hmmm I see
<andrewrk>
so you could make the "inline" aspect of it work, but the item & index values wouldn't be comptime unless the value was
<Hejsil>
Indeed
<andrewrk>
the point of inline is the comptime values though
<Hejsil>
Idk if it's a good idea, but it has to work that for tuples to be like varargs
<Hejsil>
Well, you can always use an inline while
<andrewrk>
hmmm I see
<andrewrk>
that's true, and if it works for tuples then it should work for arrays
<andrewrk>
ok I'm following along
<andrewrk>
I'm pretty sure that for loops on var args crashes the compiler right now
<Hejsil>
It does
<andrewrk>
Hejsil, this looks really good
<Hejsil>
I forgot to write tuple item access into my notes
<andrewrk>
what do you think about the idea of relying on implicit cast of inferred initializers, to remove the T { } syntax, so we can go back to the syntax that people prefer for struct / union / enum declaration?
<Hejsil>
Hmmm
<andrewrk>
Point(.{.a = 1, .b = 2})
<Hejsil>
Interesting
<Hejsil>
It's actually a very good idea, but Idk if the problem people have is struct.{} or Struct.{}
<Hejsil>
Aka, type decl or initializer
<Hejsil>
But I like that we can get some complexity back
<andrewrk>
I would propose to remove Struct.{} since implicit casting an inferred initializer isn't that much more to type, and it's redundant
<andrewrk>
and it teaches you to use inferred initializers
<Hejsil>
Alot of stuff is comming together. I still need to figure out the best way for tuples to replace varargs
<andrewrk>
yeah I'll think about the comptime thing right now... hmmm
<Hejsil>
We are kinda turning into C
<bheads>
Would that mean you would have to use var foo: Struct = .{...}; vs var foo = Struct.{...};
<Hejsil>
C does the inferred initializers to: (struct something){.a = 1}
<Hejsil>
bheads, oooh no! Two ways to do things!
<Hejsil>
That is a good question, and idk
<Hejsil>
We already have this problem: var a: u8 = 0; var b = u8(0)
<Hejsil>
"problem"
<bheads>
i thought the secound usage was gone
<Hejsil>
Nope. u8(0) is now only an implicit cast though
<Hejsil>
Never a "hard" cast
Hejsil has quit [Quit: Page closed]
<bheads>
humm I will have to re-read that section in the docs
davr0s has joined #zig
<andrewrk>
Hejsil, what do you think about [a, b, c] for the inferred initializer syntax of tuples?
<bheads>
Would looke cleaner and different the struct initializers
<bheads>
#{a, b, c}
<andrewrk>
I think I have a workable plan for the comptime/runtime thing
noonien has joined #zig
<bheads>
I still wonder if a different symbol would look better for the initilizer syntax
<andrewrk>
the idea is: 1. don't try to solve @inlineCall / @noInlineCall with tuples yet. Just let those continue to be special case var args. Builtin functions can be var args, deal with it 😎 2. tuples are either all comptime or all runtime, just like structs, no hacks
<bheads>
a leading fdot looks like a syntax typo
<andrewrk>
bheads, it looks like that because it's a traditionally unused syntactic construct, so we're not used to it being valid anywhere. the very feeling that it looks like a syntax typo is exactly why it is so available and unambiguous
<bheads>
well before wuth it was Foo.{...} it looks correct but .{...} looks like I forgot something is all I am thinking
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
allochi has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
nikki93 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
darithorn has joined #zig
Hejsil has joined #zig
<Hejsil>
andrewrk, was thinking the same thing. The only problem then is comptime_int, but I saw you talking about having comptime_int -> int, and have int have a min max encoded in it
<Hejsil>
int<0, 10> :)
<andrewrk>
Hejsil, a nice prerequisite change might be making it so you can pass comptime_int to fn foo(x: var)
<andrewrk>
hmm I think that actually it would be pretty simple to model inferred literals with mixed comptime/runtime values
<Hejsil>
When I think about it, it sounds confusing
<Hejsil>
Makes the language weird and complicated (at least from the outside)
<andrewrk>
we also have the option to make comptime stuff an error only if it doesn't get placed in a result location
davr0s has joined #zig
<andrewrk>
e.g. const x, var y = .{1, a};
<andrewrk>
with my copy elision branch, when 1 is evaluated it has a "result location" of x, and when 'a' is evaluated it has a "result location" of y
<Hejsil>
Would that work with "var" parameters too?
<andrewrk>
when you call a function, the return value has a result location. the parameter expressions are evaluated with stack allocated result locations
<andrewrk>
so, no. we'd be stuck with the status quo problem of passing comptime values to non-comptime var parameters
<Hejsil>
I think that's fine
<Hejsil>
Most of the time people run into this problem, is when they try to print comptime_int
<andrewrk>
argeed
<andrewrk>
we can solve that with the comptime_int -> int thing
<Hejsil>
Right
<Hejsil>
What would be better. Introduce 3 new "inferred types" or add a boolean flag on the Tuple, Struct and Enum types, that indicate that they are inferred?
<Hejsil>
Hmmm... Actually, 3 new types is probably better
<Hejsil>
As inferred types don't have definitions or layouts
<andrewrk>
I think that makes sense. they're kind of string-based
<Hejsil>
string-based?
<andrewrk>
never mind, I just had some circular thoughts
<andrewrk>
I just meant that, for example, `.Foo` is kinda just a name with no other meaning. it depends on how it gets casted that determines its meaning
<Hejsil>
And they probably doesn't have a runtime representation, so you can't store them in runtime variables
<Hejsil>
Or...
<Hejsil>
Hmmmm
<Hejsil>
What happens when you pass an inferred initializer to "var"?
<andrewrk>
which kind?
<Hejsil>
Well, all of them
<Hejsil>
Or, you could probably just instantiate a tuple from the inferred tuple initializer
<Hejsil>
But enum and structs, they're value/layout depends on what they cast too
<Hejsil>
their*
<andrewrk>
enum: not allowed, unless you use comptime on the parameter
<Hejsil>
Also, you mentioned [1, 2, 3] as tuple literal. It requires endless lookahead to know the difference between a tuple literal and the array type
<Hejsil>
[expr] vs [expr]u8
<andrewrk>
oh, yeah, good point
<Hejsil>
Could be done, but
<Hejsil>
I remember a "side goal" being something like "grepability"
<andrewrk>
yeah yeah. if it's hard for the compiler to parse, it's hard for humans too
<andrewrk>
it should be easy for both
<Hejsil>
Agreed
<Hejsil>
Also, here is a plan for "pass to var". struct/enum inferred initializers can't be passed, as theres nothing we can implicitly cast too
<Hejsil>
We can always cast inferred tuple to a regular tuple
<andrewrk>
why are tuples different than struct?
<andrewrk>
oh because of structural equivalence?
<Hejsil>
Well, we could also cast to a real struct
<Hejsil>
But what layout do we chose, and all that
<Hejsil>
Tuples are trivial
<andrewrk>
yeah. and it doesn't work in status quo. we don't have to solve everything at once
<Hejsil>
And @typeOf on enum/struct inf inits also shouldn't work
<Hejsil>
They have no type yet (for the user)
<Hejsil>
Probably
<Hejsil>
Or...
<andrewrk>
the important use cases are: * printf / var args * multiple assignment / multiple return from blocks * multiple return from functions * switch expressions (enum inferred init) * fn type syntax for calling convention (enum inferred init)
<Hejsil>
Hmmmmmmmmmm...
<Hejsil>
Righto
<andrewrk>
oh and * make people want to use enums instead of bools
<andrewrk>
sweep(.UnderRug); sweep(.TrashCan); rather than sweep(true); sweep(false)
<andrewrk>
looks like Hejsil has his jet pack on..... is your next idea going to be out of this world?
<Hejsil>
Oooh god
<Hejsil>
No, my next idea is to go check if my food is done
<andrewrk>
hahahhaa
<MajorLag>
hmmm.. so I'm trying to get my projects up to current syntax and: "zig\std\io.zig:124:53: error: function with inferred error set must return at least one possible error", which is InStream.readFull.
<andrewrk>
MajorLag, can you try changing the return type of InStream.readFull from `!usize` to `Error!usize` ?
<andrewrk>
same with the read function
<andrewrk>
there's an open issue for the ergonomics of this error
<MajorLag>
just changing readFull to either Error! or error! makes it compile.
<andrewrk>
ok, I'll push that
<andrewrk>
does it fix it if you change only fn read to Error!
<andrewrk>
?
<MajorLag>
nope
<MajorLag>
I think there's an open issue for this
<andrewrk>
there is
<andrewrk>
pushed
<MajorLag>
thanks
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hejsil has quit [Quit: Page closed]
tom1998 has joined #zig
davr0s has joined #zig
<tom1998>
Hey andrewrk, what's the current state on @reify? github issue seemed to leave it a bit of a cliffhanger as far as I understand, I have a use-case I could provide (although it seemed like you already had one & you were just mulling it over) - Assuming it does get approved, what's the barrier for implementing it? Are you pushing for the stage 2 compiler first?
<andrewrk>
if it gets implemented it will be in stage1 & stage2 both
<andrewrk>
it's still in the design review phase, so use cases are encouraged
<tom1998>
Okay, I don't 100% understand the current use cases published, have you heard of an 'Entity component system' in terms of its use in game development?
<tom1998>
Just so i don't re-submit another duplicate use-case without realising, plus knowing you have the understanding of that means I don't need to find a more general case
<wink_>
dl-zig-demo) and Marc's (https://github.com/tiehuis/zig-sdl2). Marc's been worked on recently so I'm leaning to go that way, any other reason to choose one over the other?
<Hejsil>
As for the removal of normal initializers, I think that is the step to take after all this is done, so idk if I should post that too
<Hejsil>
This is a multi step process in it of it self
<Hejsil>
1. Implement tuples
<andrewrk>
agreed
<Hejsil>
2. Implement inferred initalizers
<Hejsil>
3. Remove varargs
<Hejsil>
0.4.0. The Zig we knew and loved is gone :)
<Hejsil>
Better break the language while we can, in my opinion
<andrewrk>
agreed. I'm ok with master being a bit unstable right now
<andrewrk>
0.3.0 is a reasonable target for the next 6 months
<andrewrk>
for people to use if they want stability
<Hejsil>
Yea, 0.3.0 is pretty good.
<Hejsil>
If you don't do crazy stuff
<andrewrk>
ah I see you removed the `for` part
<andrewrk>
we can revisit that later
<Hejsil>
It's a thing I can live without. I think it makes sense that inline for makes everything it iterates over comptime known
<MajorLag>
Lately I've been considering trying to put some of my code into std, just so I don't have to maintain the syntax. If only my proxmox server hadn't exploded recently...
<andrewrk>
MajorLag, are you referring to the big syntax change that just happened?
<Hejsil>
Sorry~
<andrewrk>
there's a branch of `zig fmt` that will do all the fixes for you
<MajorLag>
Eh, it's what you sign up for when tracking master on a pre 1.0 language.
<Hejsil>
I'll wait with my projects a bit, as more changes are comming
<MajorLag>
andrewrk: problem there is it would ruin all my non-standard formatting.
<Hejsil>
I'd be cool to have a zig fmt pass that can translate from 0.3.0 -> 0.4.0
<andrewrk>
Hejsil, "They also implicitly cast to arrays/slices, if all their elements are the same." -> I think we can make this even better, they implicitly cast to arrays/slices, if all their elements can be implicitly casted to the array/slice element type
<andrewrk>
tuple.{u1, u2, u3, u4} can implicitly cast to [4]u8
<Hejsil>
Hmm
<Hejsil>
Well tuple.{u8, u16} should probably not cast to [2]u16
<Hejsil>
Their layout is different
<andrewrk>
even tuple.{u8,u8} layout is different than [2]u16, right?
<andrewrk>
oops, than [2]u8
<Hejsil>
I think it would be the same, right?
<Hejsil>
Why would a tuple.{u8,u8} be different from [2]u8
<MajorLag>
only if tuples follow struct layout rules, which I think the proposal explicitly said they didn't.
<Hejsil>
I actually don't know what they layout of a tuple should be
<Hejsil>
Hmmm
<andrewrk>
hmm I'm thinking
<Hejsil>
I did not think everything through!
<MajorLag>
What's the virtue of being able to cast to arrays anyway?
<Hejsil>
Actually, what is the usecase for tuple->array anyways
<Hejsil>
^
<andrewrk>
I agree that use case is not important
<Hejsil>
Idk, I remember we talked about it, but forgot why we needed it
<andrewrk>
although it might be nice to get rid of separate array init syntax and tuple init syntax
<Hejsil>
They are the same
<Hejsil>
At least in my proposal
Hejsil has quit [Quit: Page closed]
<andrewrk>
yes that makes sense. so each value in the inferred tuple initializers has to be able to implicitly cast to the array element type, and that's it
<andrewrk>
I think it might be worthwhile to not allow casting from tuples to arrays, and let the layout of tuples be unspecified. then zig is free to insert safety fields and stuff
<andrewrk>
that's the pattern with struct, union, enum
Hejsil has joined #zig
<Hejsil>
Alright, I just removed that usecase. I'll be off for now, and see the aftermath tomorrow
<andrewrk>
or we can allow implicit casting to arrays - and it would be equivalent to using a tuple initializer
<andrewrk>
so they don't all have to be the same - the code generated would be an implicit cast + store pointer for every element
<Hejsil>
I think we should find the usecase before having the casts :)