ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
clownpriest has quit [Ping timeout: 264 seconds]
arBmind has quit [Quit: Leaving.]
<Tobba>
skyfex: I feel like One Way might not *entirely* stop you from having an optional borrow checker... if you were able to implement it as a library
<Tobba>
of course that requires a pretty high caliber of CTFE shenanigans, but zig's comptime is really leaning in the right direction
<Tobba>
and well; move semantics
<Tobba>
by the way; andrewrk: is there any "official" stance w.r.t move/copy semantics, destructors and linear types?
<andrewrk>
Tobba, destructors - yes, the official plan is to not have them
<andrewrk>
the other stuff, no official stance yet as I flesh out the other language decisions
<Tobba>
andrewrk: figured; I guess compiler-inserted function calls would be somewhat antithetical to zig
<andrewrk>
Tobba, yeah. so far we have No Hidden Control Flow
<Tobba>
I found an alternative way of doing it in the current iteration of my toy language, but it even that would be somewhat magical flow control
<andrewrk>
what's your toy language?L
<Tobba>
a half-finished mess; but the rules wrt destructors is that every use of a variable becomes a normal reference, except the last one, which becomes a movable reference
<Tobba>
and every variable must be used at least once
<andrewrk>
interesting
<Tobba>
you get destructors out of that by defining a cast from a moving reference to a normal one that destroys the value afterwards (this is also a bit funky though)
<andrewrk>
what about multiple references?
<Tobba>
at the moment it's just based on lexical order
<Tobba>
I'm still trying to work out the memory management semantics of it all though
<Tobba>
I mean, it's still basically magic flow control, it's just not done directly by the compiler
<Tobba>
oh; after a moving reference is passed as an argument, accessing an existing reference is UB (not entirely ideal)
<Tobba>
andrewrk: something that might actually be interesting for zig: to partially avoid the "only certain types may be passed by value" quirk, accessing a variable actually calls the reference operator; built-in references/integers simply return the same value
<Tobba>
I mean that's ostensibly compiler-inserted flow control, but at it's at least consistent about it
<andrewrk>
> accessing a variable actually calls the reference operator
<andrewrk>
this is already true behind the scenes
<andrewrk>
kind of
<Tobba>
neat
<andrewrk>
how does that avoid the quirk though?
<andrewrk>
what we actually need is a way to say: i want to take a parameter, which is either a reference or a copy, and if it's a reference then the underlying value will not change at least until I return
<andrewrk>
then zig can pass the value however it sees fit
Tobba has quit [Read error: Connection reset by peer]
Tobba has joined #zig
<Tobba>
andrewrk: oh, right; important detail is that function arguments are taken to have the type of a moving reference inside the function
<Tobba>
which I realize now doesn't transfer too well, but it means T becomes T&& while T& stays T& since it would return itself