<andrewrk>
I found a way to proceed with #1717 and feel good about it
<mikdusan>
excellente 🍻
foobles has quit [Remote host closed the connection]
foobles has joined #zig
<foobles>
=D =D =D =D =D
<pixelherodev>
Another Zig kernel? :D
<pixelherodev>
:(
<foobles>
what?\
<pixelherodev>
Sorry, got distracted by a pm
<pixelherodev>
It barely supports more than mine does
<pixelherodev>
I really really want to work on a common kernel *framework* for Zig
<pixelherodev>
Instead of making an ambitious project myself, make a simple framework others can use
<pixelherodev>
Different ambitious project though, instead:
foobles has quit [Remote host closed the connection]
<pixelherodev>
After a bit of work the past few days, I now have two mostly working components: LLVM IR parser and tree builder, and a low-level x64 code emitter
<pixelherodev>
I wonder what happens when I put the two together? :D
<fengb>
A spectacular event
<pixelherodev>
Yep
<pixelherodev>
Both will implode in a beautiful manner
<pixelherodev>
Uh, that is, everything will turn out fine always
nephele has quit [Ping timeout: 272 seconds]
nephele has joined #zig
ur5us has quit [Ping timeout: 246 seconds]
naught-fowl has quit [Remote host closed the connection]
<andrewrk>
sorry got distrated by a situation at home, meant to follow up that with a proposal. give me 15 min
<hryx>
I am dying to know.... obviously ^_^
jwmerrill has joined #zig
<pixelherodev>
Funtime project: implementing an interpreter for the system I have a JIT for
<pixelherodev>
Interpreter is simpler to debug, and can then be used to debug the JIT automatically
<jwmerrill>
Is there a convention in zig about when a struct should have a create function vs an init function?
<pixelherodev>
But, well, I was in the process of writing a complex testing framework
<pixelherodev>
when I realized I have the entire ROM embedded in memory
<pixelherodev>
Even better, it's embedded at comptime
<pixelherodev>
I could have a comptime interpreter and compare the results at runtime
<pixelherodev>
So that debug mode can verify on a per-block basis that the result is correct
<pixelherodev>
No no no, that's overkill.
ur5us has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
knebulae has quit [Read error: Connection reset by peer]
foobles has joined #zig
<foobles>
andrewrk how do you generate a short-circuiting boolean and/or expression directly in analysis? I tried doing `ir_build_bin_op_gen`, but that didn't seem to work :p
<foobles>
(also i understand if you are busy, i have just asked this around in several places and noone has had a direct answer)
<foobles>
i assume the short-circuiting logic is somehow generated in the 1st pass?
<andrewrk>
foobles, yes - all the generation of control flow logic happens in pass 1. the second pass performs the control flow during analysis
<andrewrk>
so to do short circuiting logic, you would simply not analyze the dead branch
<andrewrk>
pass 2 is *doing* the control flow
<foobles>
how is the analysis doing control flow if all of that is determined at runtime?
<foobles>
(unless its comptime known)
<andrewrk>
I see, I thought you meant a comptime branch
<andrewrk>
can you zoom out a bit? what are you trying to do?
<andrewrk>
err I mean what are you working on?
<foobles>
the optional comparisons still =#
<foobles>
i got comptime working!
<foobles>
i was trying to do this transformation: x == y becomes
<foobles>
`(x is null == y is null) and (x is null or x.? == y.?)`
<foobles>
and x != y becomes
<foobles>
`(x is null != y is null) or (x is not null and x.? != y.?)`
<andrewrk>
you can always invent a new Gen instruction, and then do that logic in codegen.cpp with llvm ir directly
<foobles>
ooh that would work
<foobles>
i hadnt thought about that
<andrewrk>
it might even be more efficient
<foobles>
but wouldn't that also require knowing the types at pass 1?
<foobles>
because this should only be generated when the operands are options
<foobles>
and i thought pass 1 didnt know the types
<andrewrk>
how is pass1 related?
klltkr has quit [Ping timeout: 265 seconds]
<pixelherodev>
If I embedFile the same file twice, it'll only appear in the binary once, correct?
<foobles>
andrewrk I thought pass 1 was the gen-instructions
<foobles>
and didnt do type checking
<foobles>
while pass 2 evaluates comptime and does typecheckng stuff
<andrewrk>
pass1 is src, no type checking. pass2 is gen, all semantic analysis
<foobles>
right. so if I write my own gen-instruction (which is pass 1 right? all of them are labelled ir_gen_x), I would need to know during pass 1 that the operands are optionals
<foobles>
but typechecking is only done on pass 2
<foobles>
right?
<foobles>
so how would i know in pass 1 which gen instruction to call?
<andrewrk>
foobles, IrSrcGen corresponds to pass 2
<andrewrk>
argh. sorry. IrInstGen
<andrewrk>
I think the confusion here is that the pass1 functions have "gen" in them
<foobles>
oooh thats what i thought ok
<foobles>
i thought you were saying a `ir_gen_*` function, meaning pass 1
<andrewrk>
"gen" is a bit overloaded here
<foobles>
heh
<foobles>
so I would create a new type of IrInstGen node, with its own codegen as well
<foobles>
?
<andrewrk>
yes. that's probably the most straightforward way to do it
<andrewrk>
unless an existing IrInstGen already does what you want, which does not appear to be the case
<foobles>
awesome
<foobles>
cool thats super clear, ive been stuck for a few days '=D
<foobles>
tysm
<andrewrk>
no problem, good luck
dimenus has quit [Ping timeout: 256 seconds]
knebulae has joined #zig
<pixelherodev>
What's a good way to access a structure as a `[]const u8`? `@bitCast`?
<andrewrk>
slice a pointer
<pixelherodev>
You mean std.mem.toSliceConst(u8,...) it?
<shakesoda>
ptrcast to u8[*] and slice to sizeof the type?
<shakesoda>
that's what i would try first
<pixelherodev>
@bitCast seems to work, even if it's not the best option
<andrewrk>
pixelherodev, oh, does std.mem.asBytes do what you want?
<pixelherodev>
Ohh, probably
<pixelherodev>
I'm currently using std.testing.expectEqual(@bitCast([@sizeOf(@TypeOf(recompiler.state))]u8, recompiler.state),@bitCast([@sizeOf(@TypeOf(interpreter.state))]u8, interpreter.state));
<shakesoda>
that line is terrifyingly long
<pixelherodev>
(assuming I typed that correctly in IRC)
<pixelherodev>
Yeah
<pixelherodev>
Easier solution: splitting it up into multiple comparisons
<pixelherodev>
`error: expected type 'dynarec.ebus.struct:9:16', found 'dynarec.ebus.struct:9:16'`
<pixelherodev>
Ah, generics
<pixelherodev>
Okay, now it works :)
<pixelherodev>
Just made the State struct separate from the generic type
<pixelherodev>
Also works as a testing framework :D
<fengb>
Doh, mikdusan commented right befor me
<mikdusan>
yaay
<fengb>
Now I look schizo
<mikdusan>
I think .field is superb; and commas be gone; but I know this line of thinking is much wider in scope than the proposal
<fengb>
Yeah I like the pretended dot too
<andrewrk>
mikdusan, what's the .c := 10; do in your example?
<mikdusan>
oh it shouldn't be comptime. one sec.
<mikdusan>
changed rhs to bool literals
<andrewrk>
what does the .c := true; do?
<mikdusan>
.c: bool = true;
<fengb>
Default value I presume
<mikdusan>
inferral syntax
<andrewrk>
ah ok, this would introduce type inference of fields
<mikdusan>
yes. sorry I get so ahead of myself
<andrewrk>
it makes sense to show the full vision :)
<fengb>
Hmm so we have `comptime foo = bar` as well?
<andrewrk>
yes we have comptime fields
<fengb>
Hey you stole my old inferred field proposal 🤨
<andrewrk>
comptime foo = bar is not meaningful. all globals have comptime initialization expressions
<fengb>
Oh right
waleee-cl has quit [Quit: Connection closed for inactivity]
<mikdusan>
andrewrk: is #498 destructure to mean `:=` fails like go-syntax does for distinguishing between init and copy?
<andrewrk>
I'm not sure what you're asking
<mikdusan>
ah yes. you clarified before me.
<mikdusan>
thanks
<andrewrk>
the #498 plan is multiple lvalues on the LHS and then `=` and then a tuple with matching len on the RHS
darithorn has quit [Quit: Leaving]
mcf has quit [Excess Flood]
mforney has joined #zig
mforney is now known as mcf
<daurnimator>
feels odd that globals and args are const-by-default but pointer-values are not
<foobles>
hmm true
<daurnimator>
if we have a general attitude of const-by-default then `*T` should mean pointer to const T, and you need e.g. `*var T` for a non-const pointer.
<hryx>
mikdusan: I added my own suggestion inspired by yours
<mikdusan>
ideas. I seee everyone has ideas within ideas. Andrew lit a firestorm. some real neat stuff coming out.
<mikdusan>
being suggested
<foobles>
i like this :)
<foobles>
0.7.0 is going to be like C++11 was to '98 :P
<foobles>
even more!
<foobles>
becasuse breaking changes!
<hryx>
o no mikdusan did I actually just repeat what you said? Maybe I misunderstood :(
<hryx>
(in the GitHub comment)
<mikdusan>
hryx: looks very similar
<foobles>
I think you just didnt see his link to what he posted in the other issue
<hryx>
Dang, I thought you were suggesting actually using the := operator. so that's not the case?
<foobles>
I am now :)
<foobles>
but he originally was, but modified his propsal
<mikdusan>
i knew someone was going to flip `:=` to mean reassignment
<andrewrk>
if you look at your own code, and try modifying it to my latest proposal there, it's pretty surprising few rarely you actually need the `mut` keyword for reassignment
<andrewrk>
s/few/how/
<mikdusan>
andrewrk: when I heard that I said what? waaat? but then yeah I can believe it.
<andrewrk>
it was *zero* in the file I translated
<hryx>
I like the mut quite a bit, but the disconnect with += and family might be a gotcha/surprise
<hryx>
the low impact is nic3e
<hryx>
*nice
<foobles>
I also dont like how it's inconsistent with other types of reassignment
<andrewrk>
it's impossible to mess up. any mistake leads to a really straightforward compile error
<andrewrk>
someone could learn this syntax without reading language documentation
<mikdusan>
foobles: what I like about your flip `:=` idea is this; consider andrew mentioned that reassignment is few compared to decl. so that relaxes the amount of `:` required in destructuring!
<daurnimator>
andrewrk: I see the merit in your proposal.... but it makes things very unfamiliar
<foobles>
mikdusan oh yeah! Maybe if I mix mine and your proposal: a `:` after something means a redeclaration
<daurnimator>
--aprochability
<foobles>
s/redeclaration/assignment
kenaryn has joined #zig
<kenaryn>
Hello you C/C++ programmers who dream of a Zig job all nights. Please is there a simple method to remember when do I have to use `std.debug.assert` or `std.testing.expect`?
<andrewrk>
kenaryn, yes. is it in a test block? expect. otherwise, use assert
<kenaryn>
Thank you sir.
<mikdusan>
foobles: I think inverting `:=` makes an ambiguity in destructuring (as I styled it)
<foobles>
yeah, you are right
<foobles>
especially with explicit types
<hryx>
mikdusan:
<foobles>
i think the best way to go is how andrewrk said, but with something other than a keyword, and make it consistent for all reassignment
<foobles>
like a prefix-operator you put
<hryx>
oops, mikdusan, with a destructuring example, would yours and mine look the same?
<kenaryn>
In Backus-Naur form (a logical-mathemathical expression), you have `::=` notation to express 'defined as the following'.
<hryx>
I see now, I was looking in the wrong place. Sorry about that foobles, I'll correct my comment
<andrewrk>
foobles, I like the way your latest comment addresses the consistency issue
<foobles>
:)
<andrewrk>
let's see if we can improve it even more, with the use case of someone who does not know zig, but knows other programming languages, reading zig code
<andrewrk>
and they see reassignment syntax (in context)
<andrewrk>
I feel that ~ might be a bit of a red herring with bitwise not
<andrewrk>
that's a really good point, what this really comes down to is, what is the syntax sugar for (&x).*
cole-h has quit [Quit: Goodbye]
<foobles>
I agree, ~ is weird. I do think it should be `.something` though
<foobles>
what about `.mut`?
<foobles>
eeeh, the more i look at that the more i dislike it
<foobles>
especially since it will look like a member
<foobles>
i do think it should be postfix though
<foobles>
and start with a `.`
<hryx>
x._
<shakesoda>
I feel like there are several proposals (some accepted) for the compiler just erroring out on style issues that seem... a bit ridiculous
<shakesoda>
in terms of "why on earth is this an error and not just a cosmetic fixup for zig fmt"
foobles73 has joined #zig
foobles73 has quit [Remote host closed the connection]
foobles22 has joined #zig
<foobles22>
I like `._` its definitely not as weird as `.~`
foobles22 has quit [Remote host closed the connection]
<shakesoda>
also, i actually like the const foo = fn syntax :(
<kenaryn>
`|~`
foobles93 has joined #zig
<hryx>
foobles22: if you want a dot-something glyph you could also consider `.@` which kiiiinda suggests something about a variables "self property"??
<andrewrk>
shakesoda, you like it better than foo = fn syntax ?
foobles has quit [Ping timeout: 240 seconds]
foobles93 has quit [Remote host closed the connection]
<andrewrk>
field access syntax is a bit problematic because in the reassignment, the lvalue could be a struct type
foobles has joined #zig
<andrewrk>
shakesoda, re: style issues - which proposals are accepted?
<kenaryn>
`@_`
<foobles>
so like `x@_ = 10;`?
<hryx>
problematic, true. `@=` ? It is sort of in line with += and familly
<foobles>
we can't just add another operator, since that gets wonky with multi-assignments
<foobles>
also im really loving this conversation but i have some stuff to get done
<foobles>
hopefully ill be back soon
<kenaryn>
See ya=)
<andrewrk>
what was the problem with `mut a = b;` ?
<hryx>
sorry all, I'm probably too wound up by the topic and repeating things others have said. I'm going to leave this to the experts for now :)
<hryx>
andrewrk: I really like the `mut` but my concern was it's disjointed from other reassignment ops like +=
<hryx>
But probably a non-zig user should be the one to chime in on that like you said
<shakesoda>
andrewrk: yeah, I like const foo = fn() more with the const than without, and if it's only a global scope thing then it's just inconsistent. further, suddenly I have to @as at global scope to actually write a type in or something? that just... doesn't seem desirable. also, if this affects declarations in structs then the difference between = and : is suddenly severely harmful to legibility
<shakesoda>
I had to read some of the example posts mentioning that several times to even get it
<shakesoda>
I don't want that problem in my code, it feels... frustrating
<andrewrk>
shakesoda, the latest iteration of the design, it's both global and local
<andrewrk>
can you help me understand why you would rather start typing an extra keyword for all function declarations?
<andrewrk>
as opposed to not start typing an extra keyword for all function declarations
<mikdusan>
andrewrk: global `mut i = 5;` would be error correct?
<shakesoda>
because then I don't need special rules depending on typing them inside of a function or outside of it
<mikdusan>
err `mut i: u32 = 5;`
<shakesoda>
the const assignment syntax is identical everywhere, no special rules here
<andrewrk>
mikdusan, correct
<andrewrk>
shakesoda, did you see the part where I wrote, "I realized that this proposal has one really big downside: it makes it no longer possible to cut+paste constant declarations from global to local scope, and vice versa." and then changed the whole proposal?
<shakesoda>
if it's both global and local then you also add a new problem of it being hard to actually see where first declarations are
<shakesoda>
andrewrk: no, just getting to that one now
<shakesoda>
mut on reassignments feels even worse than just keeping the consts
<shakesoda>
it solves the problem of initial declarations being hard to spot, though
<shakesoda>
but I don't think it's an *improvement* over const
<andrewrk>
mikdusan, your tuple syntax is off
<andrewrk>
also s/default value// for the globals
<mikdusan>
yeah i nuked default global already
<mikdusan>
I don't know how to say it clearly; I wanted tuples on RHS to just show the types
<andrewrk>
I see
<mikdusan>
ie: indicate first lhs gets first type, 2nd lhs gets 2nd type
Xavi92 has joined #zig
<foobles>
my only issue with `mut` is that it looks too much like `var`
<foobles>
and therefore looks like a declaration
<andrewrk>
I see
<foobles>
maybe if mut just came afterwards?
<foobles>
`x mut = 10;`
<foobles>
then it looks like `mutation assignment` even :)
<shakesoda>
andrewrk: the other accepted style issue i was thinking (which I believe to be zig fmt's domain and not a reasonable error) is #35
<andrewrk>
var a, x mut, c = .{1, 2, 3}
<shakesoda>
i.e. "error on bad indentation"
<andrewrk>
wait really you have a problem with that? but it prevents a footgun
<shakesoda>
the only footgun I'm thinking of is brace omission errors, and brace omission is a feature I don't like either :\
<shakesoda>
despite it being currently how ternary works
<Xavi92>
Hi there :)
<foobles>
hello
<Xavi92>
Just reading #5076 as well
<Xavi92>
andrewrk: "The keyword const is then only used for pointer attributes, and it would set the stage for a follow-up proposal that deleted the const keyword altogether and used mut to annotate mutable pointers." -> does that mean Zig would finally switch to '[]T' and '[]mut T'?
<andrewrk>
yes
<shakesoda>
naked const assignments have some benefits but I don't feel like it's good for consistency or legibility, and even with the added mut on reassignments (which resolves the ambiguity) I'm really hesitant to think it'll make my code better to read
<Xavi92>
andrewrk: well, that's a relief after seeing my issue closed down :)
<foobles>
:-) i was worried about that too
<shakesoda>
especially when historically it hasn't actually been a problem in other languages I write that accept function definitions in the proposed form of 1717
<shakesoda>
ymmv, of course
<Xavi92>
shakesoda: I agree. IMHO local scopes would be the only place where 'const' makes sense to me, making more readable than e.g.: a special syntax for reassignments
<shakesoda>
I'm all for const being allowed everywhere
<Xavi92>
andrewrk: OTOH, I like the decision to drop 'const' on struct and enum definitions. I already felt that the first moment I started learning Zig
<shakesoda>
as is the status quo
<shakesoda>
although I wouldn't complain either if const were shorter... perhaps let ;)
<foobles>
how about `c`
<shakesoda>
(or even... set)
<foobles>
:p
<mikdusan>
it's too bad this word is so bloody common; `reset` to reassign, and `mut` to mean mutable in both values and pointers
<shakesoda>
feels very strange to be the one not in favor of removing some syntax i have to say
<foobles>
I think if `mut` is added, it should be equivalent to `(&x).*`, and thus usable as an expression
<shakesoda>
since i'm almost always in favor of such things
<foobles>
heh
<foobles>
like some kind of "assignable identity"?
<mikdusan>
honestly this topic has stolen. STOLEN. 4 hours of my life. I thought it was just 1 hour lol
<shakesoda>
it's kind of a big deal that would affect all zig code, all of it.
<shakesoda>
1717 would too, but i think in a more trivial way
<foobles>
hmmm
<foobles>
well one thing could be interesting: sort of like rust, if we add prefix mut like that
<foobles>
we could have `&mut x` for a mutable pointer
<foobles>
and `&x` is always constant
<foobles>
but then that sets a precedent for prefix-mut
<foobles>
which is bad looking on assignments
<andrewrk>
mikdusan, your , ; thing affects enums too. it looks weird with enums
omglasers2 has joined #zig
<andrewrk>
thejoshwolfe suggested that zig fmt could auto-fix between , and ; for struct fields and switch cases
<foobles>
wait a second, this might be just terrible
<foobles>
how about `x. = 10` for assignment
<foobles>
postfix `.` :))))
<mikdusan>
oh if it's just about enum decl, yeah, that's a special case that needs thought
<foobles>
no, maybe not ....
<shakesoda>
i was thinking briefly about a .<symbol> for reassign but I can't think of any that are actually any good
<shakesoda>
some of the issue for me is that I specifically read code by looking for the initial assignment keywords
<mikdusan>
here's a slight rework to make `mut` both for values and pointers. `mut i: u32 = 0 //init;` and `reval i = 1;`
<foobles>
i like that
<foobles>
how about `ass` for "assign"
<foobles>
:v
<mikdusan>
brilliant
<kenaryn>
`::=`
<mikdusan>
i think you've been reading too much anal .cpp code
<kenaryn>
lmao
<foobles>
the issue with having a dedicated assignment operator is that it gets weird with multi assign
<andrewrk>
I like ass
<mikdusan>
:P
<shakesoda>
were this my channel you'd have that quote in the topic already
_Vi has quit [Ping timeout: 272 seconds]
<shakesoda>
i'm a bit less sure about what i think of 5077
<shakesoda>
i don't feel like it's really the compiler's business to care about field ordering as long as the syntax isn't ambiguous
<shakesoda>
fmt would fix it and i could see a warning over it, it just seems bizarre that "this is on the wrong line in the struct" is a syntax error
<shakesoda>
especially when if your struct has some big functions or something there's a really high chance you'll keep a var near you so you can still see it
<shakesoda>
it's easy enough to argue against writing code that way, but it just seems like overreaching for not much benefit
<andrewrk>
mikdusan, I think you meant to post that on the other issue
<mikdusan>
yup fixing now
<mikdusan>
SpexGuy just comment-bombed me on the auto-reload lol
<foobles>
he basically says what you said :-)
<foobles>
but also explains some more stuff
<foobles>
i actually think this should be the distinction, if we go this route:
<Xavi92>
I like 5077, actually
marijnfs has quit [Quit: leaving]
<Xavi92>
Matches Zig's one possible way to make things IMHO
<andrewrk>
set is pretty good
<andrewrk>
I have to admit set is better than ass
<mikdusan>
yes 5077 is nice esp with SpexGuy relaxing it a bit to mean "no non-fields between fields" ... so NNFBF
<andrewrk>
you can read `set b = 4;` without any context and any docs
<Xavi92>
andrewrk: if `let` isn't an option, I also prefer `set`
<andrewrk>
let looks like a decl
<mikdusan>
well set and let are both tennis words. but let is really a tennis word to me.
<shakesoda>
let is a difficult to understand math paper word to me
<Xavi92>
andrewrk: Just to ensure I understood it correctly, would `set`be used in place of `const` or used for reassignment?
<shakesoda>
i'm not massively opposed to spexguy's .~ reassignment although i still hold that i think the proposal isn't an improvement
<andrewrk>
one thing to remember is that big syntax changes feel very strange when they first happen and it's difficult to overcome the cognitive bias that we all share for status quo
<Xavi92>
shakesoda: I'm against introducing new operators, or at least .~ looks like an operator to me
<shakesoda>
i think it pulls zig further from being simple and consistent (just more terse), rather than closer
<shakesoda>
Xavi92: it's at least not something alien if you've seen a .*
<shakesoda>
i.e. it's in the same form as other things already are
<Xavi92>
shakesoda: .* was also alien for me :) At least as soon as I realized *foo triggered a compile error
dermetfan has joined #zig
<andrewrk>
shakesoda, I agree with you that my proposal makes the language bigger
<Xavi92>
andrewrk: referring to 5077 you mean?
<andrewrk>
sorry, I'm referring to 5076
<shakesoda>
5076
<shakesoda>
5077 (no ungrouped fields) is one i'm against being a compile error but in full support of being an fmt fixup
<andrewrk>
shakesoda, I noted on that issue about zig fmt at the end there, not sure if you caught that
<shakesoda>
andrewrk: I think it's a strong point for a warning or for fmt, I don't feel like it's strong enough for an error though.
<shakesoda>
andrewrk: leaves me a bit on the fence about it, really
<shakesoda>
in general, I don't feel anything which is fundamentally just bad style should be an error
<andrewrk>
5077 is small fish, hard for me to even care about it when 5076 is on the table
<shakesoda>
5077 is indeed a small fish
<shakesoda>
heh, I was thinking of set as replacing const instead of mut.
<foobles>
After looking it over from a bunch of perspectives, I think `set` is the best in this case
<shakesoda>
but set is also a lot better than mut in this context
<Xavi92>
I'm also convinced on `set` and `var` (unless I got something wrong all out of this)
<shakesoda>
Xavi92: the proposal is something else entirely right now
<shakesoda>
unless you happened to just read the comment on 5076
<Xavi92>
shakesoda: I was expecting that somehow :P
<Xavi92>
So what's the current status?
<mikdusan>
the very first line of 5076 still stands, so it shortens ALL imports. it shorts new #1717. the rest is just attempt at consistency
<mikdusan>
and addressing ambiguity
<foobles>
I am really liking `set` now
<shakesoda>
we could also shorten everything just by swapping const with set, without changing the rules
<mikdusan>
but that's longer than functions as I see it in 5076
<foobles>
i just posted a new comment
<foobles>
i think `set` should be used in all reassignments, just for consistency
<shakesoda>
I rather think it's trivial if the cost of anonymous functions is two more characters.
<Xavi92>
mikdusan: I agree with the first line from 5076. I'd just replace `const`by `set` on local scopes, and `var` by `mut`
<mikdusan>
foobles: i think that is idea. you cannot mutate an existing value without a `set` ?
<shakesoda>
when you can reclaim both characters by shortening const, lol
<foobles>
mikdusan the original proposal had stuff like `x[0] = 5;` being allowed without mut
<foobles>
only direct `identifier = expr;` needed `mut`
<foobles>
but since thats inconsistent, I think reassignment even when it isn't ambiguous should use `set`
<foobles>
like `set x.* = y;`
<mikdusan>
foobles: oh right i see that now. "assignment that do not look like a = b; are unchanged"
<andrewrk>
foobles, what about +=
<foobles>
I think those should be left alone. you arent directly "setting" them as I see it, those are more so "modification operators".
<foobles>
they wouldnt work in multi-assign anyway
<foobles>
like they "adjust" instead of ignoring the old value
<mikdusan>
probably limiting the `set` idea to just disambiguate "a = b" is good. it shouldn't go viral
<foobles>
so what do you think of `set x[0] = y;`?
<mikdusan>
close but no cigar
<mikdusan>
can x[0] be confused with a decl?
<shakesoda>
oh, i goofed my thinking about lengths
<shakesoda>
too late for me
<mikdusan>
shakesoda: hours stolen. HOURS!
<andrewrk>
I think the remaining issue is the point made by fengb, shakesoda, and torque: "variable declarations be specifically highlighted by keyword usage (const, var) is valuable for code comprehension"
<andrewrk>
it's tempting to say syntax highlighters can look for `a = b` and make it bold, but I think that's a cop out
<andrewrk>
although I will show what that looks like just for fun
<Xavi92>
andrewrk: that makes code comprehension depend solely on the editor, though. A keyword is a good balance when no syntax highlighter (or a bad one) is present
<foobles>
yeah, i dont like depending on IDE features
<andrewrk>
agreed
<shakesoda>
the amount of actual brain space my function declarations take up is almost none compared to everything else, fwiw
<shakesoda>
I changed the form of functions in a file I've got open here, it looked funny for a couple seconds, and then I stopped noticing.
* shakesoda
is glad that torque is better with words...
<Xavi92>
shakesoda: could you provide an example on a pastebin? Just for curiosity
<mikdusan>
amazing how every decent operator with `=` in it is gobbled out
<mikdusan>
up
<kenaryn>
`=:=`
<kenaryn>
`<~>`
<shakesoda>
Xavi92: one moment
<foobles>
`<-`
<foobles>
:)
<mikdusan>
and as soon as an op is attempted for "reassign" it makes multi-lhs look messy
<Xavi92>
shakesoda: that function declaration style is probably not my cup of tea (I guess because of my background in C and later Rust), but makes it more consistent with how enums and structs are defined, I must admit
<shakesoda>
i certainly like the existing function syntax of just `fn`, but I don't hold it so close to my heart.
<shakesoda>
the total consistency is nice
<shakesoda>
if zig were more the type i'd say just make the current form sugar for it, but that's inconsistent with zig's philosophy and a separate discussion to duke it out over
<Xavi92>
shakesoda: totally agree with that. Being consistent is as important (if not more) as being simple
<mikdusan>
also consider for a momement how much syntax complexity andrew avoided by designing comptime with as much as the same syntax as possible. every other language fails at that. macros, annotations, weird brackets, templates
<foobles>
thats certainly true :) i was amazed when i saw generic types :D
<foobles>
but i guess `const foo = fn() void {` is OK.....
<foobles>
my only gripe is that const is slightly too long, but it seems that has already been discussed at length
<torque>
yeah, I think the main thing that is sticking for me is `const foo = fn() void {}` actually reads really well to me. Maybe I'm damaged by having written a bunch of lua/moonscript/javascript where all functions are all "anonymous" and you end up with something like `local foo = function(bar, baz) end` every time you declare a function anyway
<kenaryn>
`~@`
<Xavi92>
torque: `const foo = fn() void{}`, `const bar = enum {}`, `const baz = struct {}`. Looks pretty consistent to me
<torque>
I agree with that
<shakesoda>
point of interest: lua is my all-time favorite language by miles
<andrewrk>
consistency is a given, that's why the proposal to drop const in the global scope has so much fall out
<shakesoda>
in large part because it is relentlessly simple
<Xavi92>
Maybe replacing `const` by `set`, `let` or any 3-character keyword would be preferrable. I'm sold on `ass` too :P
<andrewrk>
forget about `set` outside the context of reassignment
<foobles>
apparently `let` is off the table too
<shakesoda>
I don't actually expect const/var to change, given older issues
<foobles>
yeah
<Xavi92>
shakesoda: I also prefer `const` tbh. I said it would be preferrable since `const` seems to have some friction among some developers e.g.: after reading #181
antaoiseach has joined #zig
<Xavi92>
But I'm totally fine with it, after all
<foobles>
so this also drops any possibility of const-by-default for pointers?
<foobles>
andrewrk
<torque>
from a more pragmatic standpoint this also seems like a huge amount of effort to solve something that isn't actually a problem. I actually only commented on the issue because it felt like people were being much to eager make sweeping changes to the language and there didn't seem to be a strong contrarian opinion.
<andrewrk>
int main() {}
<andrewrk>
pub const main = fn() void {}
<andrewrk>
zig is losing pretty hard to C here.
<torque>
losing in what metric, though?
<mikdusan>
I find the more fundamental a syntax change, the more you have to explore universal consistency
<torque>
*metrics
<shakesoda>
I don't think zig's going to be beating C at IOCCC style contests either, which isn't specifically a flaw
<Xavi92>
foobles: I think both are still possible. *Foo, *mut Foo, const main = fn(){}
<andrewrk>
functions are the foundational abstraction of the language
<Xavi92>
foobles: *const Foo wouldn't just make sense if `const` is only used to declare things.
<torque>
I mean status quo is `pub fn main() void {}` anyway, right? you're already losing anyway, so lean into it
<Snektron>
<andrewrk "int main() {}"> You meant `main(){}` ;)
<shakesoda>
kinda feel like if we're gonna put in weird exceptions it'd be a lot simpler to just syntax sugar fn
<shakesoda>
this, however, is not an issue which will keep me from going to sleep. night
<foobles>
even lua did that :p
<andrewrk>
nah no weird exceptions, no syntax sugar for fns
<foobles>
andrewrk so any final thoughts about `*var T?`
<foobles>
or was that closed the moment yoy closed the issue
<foobles>
s/yoy/you
<andrewrk>
what is your argument in favor of `*var T` over status quo?
<shakesoda>
pointer args being mutable implicitly goes against the constness of parameters
<foobles>
thats one thing
<shakesoda>
wasn't that the idea
<foobles>
and in general, I think const-by-default should be a goal of the language
<foobles>
i find myself, in C++/C, just forgetting to put `int const&`, since its so much easier to read without it
<foobles>
even though almost all of the time my references and pointers should be const
slowtyper has quit [Quit: WeeChat 2.7.1]
<foobles>
I think rust is a good example of how const-by-default syntax for pointers works in the language's favor
<andrewrk>
rust's relationship to const-by-default is deeper than zig's because of the borrow checker
<shakesoda>
rust is also a good example of how enough obsession can turn it frustrating
<foobles>
true
<foobles>
but just syntactically
<foobles>
its a warning sign in the signature: "the value will change when you pass it to this function"
<andrewrk>
zig's pointers are unambiguously mutable or const with status quo
<andrewrk>
so the warning sign is the same
<foobles>
but its so much easier to just say `*T` and forget about it. having 2 or 3 `const`s in a function signature makes it a lot harder to read i think
<foobles>
C has the same problem, someone else mentioned how much easier it is to make things not const-correct
<foobles>
and just have all pointers be mutable
<foobles>
well i guess the story is better than C, since locals have to be `const` or `var`
<andrewrk>
there's a sub-movement in the C community who think `const` is a bad language feature and eschew it entirely
<foobles>
D:
<foobles>
oh dear
<foobles>
well its not the biggest issue for me
<antaoiseach>
is this a discussion about having `const` explicitly in type signatures as opposed to implicit?
<antaoiseach>
If so, I, as a beginner to Zig, quite like the explicit const-ness in type signatures
<Xavi92>
andrewrk: yes
<foobles>
this is about pointer types not allowing mutation of the object they refer to, unless specified as `var`
<antaoiseach>
Ah, okay
<foobles>
i like it to
<foobles>
s/to/too
<foobles>
and it sets a precedent for const-by-default
<foobles>
so i feel like `*T` should be a pointer-to-const
<foobles>
especially since that is what i want 90% of the time
<mikdusan>
this would be C++ using consistent style for main: `auto main = []() -> int {};`
<Xavi92>
foobles: totally agree
<antaoiseach>
Isn't that becoming kind of Rust-ish?
<kenaryn>
`zig zen | head -n2`
<Xavi92>
antaoiseach: isn't default mutability becoming kind of C-ish?
<antaoiseach>
I thought that was the point of Zig?
<Xavi92>
antaoiseach: I'd prefer Rust over C a million times in that sense
<andrewrk>
foobles, I don't think your 90% experience is representative
<antaoiseach>
I like Rust, but that's just one way of doing it
<foobles>
ok, 90% may be hyperbole
<foobles>
but i just mean generally
<foobles>
its far safer to assume const, and then decide to change it later
<andrewrk>
I believe you - but mutable state is also a valid way to code
<Xavi92>
foobles: totally
<Xavi92>
andrewrk: we never said it was invalid. It's just risky, and thus should be explicit
<antaoiseach>
Indeed... sometimes it's just a pain (in Rust) to keeping having to dump `mut` all over the place, I find
<foobles>
right, so I think `*var T` isnt too frustrating to type
<antaoiseach>
especially when doing heavily imperative code
kenaryn has left #zig ["WeeChat 2.3"]
<antaoiseach>
that's just my experience though
<foobles>
right but how often are you specifying pointer types in zig? mostly in function signatures
<andrewrk>
in std.ArrayList nearly every pointer in the function signature is correctly mutable
<Xavi92>
andrewrk: default immutability favors assigning variables only once, rather than modifying them at several places. That causes code hunting
<Xavi92>
antaoiseach
<torque>
I don't think calling mutability "risky" is a reasonable argument. the only time it is "risky" is in badly written code, which the compiler will not fix
<andrewrk>
zig programmers are already encouraged to use const rather than var for variable declaration
<antaoiseach>
torque: agreed
<andrewrk>
however since `var` is easier to type, I have noticed people incorrectly choosing it over const
<shakesoda>
I think mutability is a lot more dangerous in languages where you can hide stuff in places that look benign
<Xavi92>
andrewrk: then encourage zig programmers to use const for immutable pointers and var for mutable pointers. That's what my proposal was all about
<shakesoda>
zig's no hidden control flow dramatically reduces the potential there
<foobles>
well take this piece of the self-hosted zig compiler: `fn genCall(irb: *Builder, suffix_op: *ast.Node.SuffixOp, call: *ast.Node.SuffixOp.Op.Call, scope: *Scope) !*Inst {`
<antaoiseach>
Xavi92: that sounds reasonable to me, but what exactly is your proposal? Is it an issue on Github?
<foobles>
from what it looks like, suffix_op and call should both be *const
<shakesoda>
risk in c++: extreme, likely lethal, you will screw up. risk in zig: well i guess if you try you can do bad things
<andrewrk>
I think the main argument in favor of #5076, despite the problems pointed out by torque, is that it actually modifies the language in a way that makes it favorable to make const decls rather than variables
<antaoiseach>
Xavi92: thank you. will check it out
<foobles>
andrewrk so why not enforce that with pointers as well?
<mikdusan>
thinking about it, I don't know why I _assumed_ that the mutability disposition has to be symmetrical for values vs pointees
<torque>
what's the primary use-case for passing an immutable pointer to a function anyway? aren't pointers generally used as an inout parameter because passing parameters directly can silently optimize to pass-by-reference when appropriate?
<foobles>
needing to return a pointer to a member is one
<andrewrk>
I'm not convinced with the self-hosted compiler function arguments foobles. I remember writing that code, and I vaguely recall trying to make something const, and then spending a bunch of time dealing with mutability of things, an hour goes by, and I realized, "I'm just playing with the type system. I'm not actually being productive." and then made everything mutable and actually got done what I wanted to get done
<foobles>
fair enough
<foobles>
i dont want to get into too much of an argument over this
<andrewrk>
I'm not on the side of that sub-movement of C people. I think const is a good tool
<foobles>
yeah
<torque>
at least in C const is usually not worth the hassle
<foobles>
i just think it should be easier to make pointer-to-const, and should be easier to declare variables as const
<torque>
e.g. prevents you from initializing a struct after allocating it
<foobles>
and also i think i should go to bed
<foobles>
good night everyone
<Xavi92>
foobles: night!
<andrewrk>
good night foobles
<andrewrk>
torque, I can give you a really clear example: it lets you know that you can pass a string literal as a parameter
<andrewrk>
otherwise you will get a segfault at runtime
<Xavi92>
andrewrk: so, to sum up and despite all of the discussion, this means everything stays as is?
<andrewrk>
no decisions have been made, no "accepted" label has been applied or "close" button has been clicked
<antaoiseach>
Having read the Github issue, I really don't know what to think - it feels kind of subjective... almost everyone's going to have different opinions I think. While I like the explicitness having something like `*var T` or `*mut T` would bring, the default being immutable and not requiring `const` still appears a bit of magic to me. Why not simply have no defaults, and make everything explicit at the cost
<antaoiseach>
of extra typing - `*mut T` and `*const T`?
<antaoiseach>
g'night foobles
<Xavi92>
andrewrk: the "close" button was pressed on #5056
<antaoiseach>
It's broad daylight here... hahaha
<mikdusan>
?
<mikdusan>
shows open to me
<andrewrk>
Xavi92, oh, 5056? yeah that's closed. so it's not planned
<antaoiseach>
shows closed for me (5056 that is)
<mikdusan>
hahah 5056 != 5076
<shakesoda>
mikdusan: not 5076!
<Xavi92>
andrewrk: I have the impression you changed your mind several times during this dicussion.
foobles has quit [Ping timeout: 240 seconds]
<andrewrk>
this is what it feels to argue with someone who has an open mind
<Xavi92>
andrewrk: some lines ago you said `*Foo` and `*mut Foo` would prefer
<shakesoda>
if it were decided already, the labels on the issue would be different
<Xavi92>
andrewrk: Now you say you don't, as you said for #5056
<andrewrk>
specifically because it would mean the removal of the `const` keyword entirely
<antaoiseach>
ohh... but I like the explicitness of `const` ;(
<Xavi92>
andrewrk: if `const` was removed, then pointers would be immutable by default, right?
<andrewrk>
5076 is a big change. it has the potential to piss off a lot of people who are currently happy and also attract people who currently are put off
<Xavi92>
andrewrk: it definitely is. But if one likes C, then stick to C. Zig should be meant (among other thing) to provide an alternative to C
<andrewrk>
Xavi92, it would flip things, yes, so `*T` would be immutable, `*var T` would be mutable
<antaoiseach>
:|
<shakesoda>
Xavi92: you don't do better than C just by alienating all the C users
<andrewrk>
change is not automatically better
<shakesoda>
it's a little more involved than that
<Xavi92>
andrewrk: alright, that's what we discussed a few hours ago, and it's what I would also prefer
<Xavi92>
shakesoda: I don't think default immutability would alienate all of the C users. It didn't alienate me, writing in C for a living
<shakesoda>
Xavi92: right, I was poking at the logic of the statement, not the point being made
<Xavi92>
shakesoda: I used that logic since I feel the impression const-correctness is not given proper importance since some C programmers just don't care about it (e.g.: the submovement andrewrk pointed out)
<daurnimator>
FWIW I don't like destructing assignment.
<Xavi92>
But I'm glad Zig moves towards default immutability
<shakesoda>
const correctness in C isn't something I personally give much a crap about either
<shakesoda>
but it's not because I don't give a crap about it, it's more because of how much of a hassle it is in C and C++
marijnfs has joined #zig
<Xavi92>
shakesoda: that's why zig should make const-correctness easier
<shakesoda>
zig already makes it so much better that I const nearly everything
<antaoiseach>
Is there a consensus here? It's a bit confusing...
<daurnimator>
I like that it requires a keyword to introduce a new variable
<shakesoda>
daurnimator: I like destructuring just for effectively letting you have multireturns
<shakesoda>
one of the lua features I really like
<daurnimator>
I've learned that local-by-default is wrong; global-by-default is a foot-gun but required if you want to be config-language-like; so explicit new variable declaration with a keyword is the best option left
<andrewrk>
torque, will you humor me? try converting 1 file from your project over to the proposal of #5076 and re-read the file, with an open mind to the new syntax
<daurnimator>
shakesoda: lua *does not* have deconstruction. its very important to note that it has multiple assignment
<andrewrk>
and then tell me your honest opinion
<shakesoda>
daurnimator: I know lua doesn't have it, I just mean that this in zig means we can have something vaguely similar
<antaoiseach>
Where can I see this destructuing syntax? 5076?
<antaoiseach>
destructuring*
<torque>
andrewrk, I need to go to sleep (2am here). I will take another look at this tomorrow morning, though
<andrewrk>
torque, good night and thanks for your thoughts
<shakesoda>
andrewrk: I changed one of my files this way and I'm having trouble actually finding my variables
<shakesoda>
the functions read fine
<andrewrk>
when you say "find", can you elaborate?
<andrewrk>
if it's a literal search, you can do `foo =`
<shakesoda>
I mean I can't scan for my const assignments in blocks
<andrewrk>
I experienced that feeling too, but I wonder if it is because we are used to using certain visual cues
<shakesoda>
I can search for =, but I can't see the things among other code as I could the keyword
<andrewrk>
or if something is actually now worse
<shakesoda>
I've also had this problem in, say, python.
<shakesoda>
it's one of the things I don't like about it
<shakesoda>
if I highlighted all my = signs as magenta or something I'd probably be able to mitigate it
<andrewrk>
it is regexable
<andrewrk>
but I'm not sure that's enough. I wonder if we can quantify the problem
dddddd has joined #zig
kenaryn has joined #zig
<kenaryn>
Please what purpose does a sentinel-terminated array serves?
<kenaryn>
Is it useful when not dealing with any C code base?
<andrewrk>
it's the type of string literals, makes it so you can cast string literals to both []const u8 and to null terminated pointers
<kenaryn>
Thanks again andrewrk.
<nmeum>
Hi, I am currently working on the Alpine Linux Zig package. As part of that package I would like to run the test suite using `./zig build test`. All tests seem to pass but `./zig build test` fails with an `unable to spawn …` error message https://tpaste.us/mEXV any idea what I am doing wrong here?
<mikdusan>
someone suggested `def` keyword, I interpreted it to mean `const` for decls:
<mikdusan>
meh i forgot it of course for the Foo :(
waleee-cl has joined #zig
<Xavi92>
mikdusan: why the `.` or `def` prefixes on struct members?
<mikdusan>
`def` means immutable decl. `.` prefix identifies fields and drops use of `,` after field and uses `;` . this was another suggestion. I'm combining suggestions that seem to work together
<mikdusan>
that combo is obviously a backtrack on the no-keyword = const decl + `set` for reassign
<Xavi92>
mikdusan: unfortunately I don't understand the difference between, for example, `.a: u32;` and 'var a: u32;`
<Xavi92>
mikdusan: I see one means 'field' whereas the other means 'decl rw', but I don't get the difference. Probably it's just me
<andrewrk>
nmeum, I think you could do just fine with a subset of the tests
<andrewrk>
nmeum, but perhaps that is an upstream issue we could look at
<mikdusan>
nmeum: quick question: how much memory does alpine have?
<afontain_>
what does that mean?
<nmeum>
we have different builders with different resources available to them but it probably make sense to run a subset of the test suite, yes
<mikdusan>
any idea how much? 4 GiB is likely not enough. 6 GiB is comfortable.
<mikdusan>
RAM.
<nmeum>
most builders should have more than that iirc, but the limiting factor is probably build time anyhow
<nephele>
For compiler-rt, the input and output have to be C-values, but inside i can use zig values, is that correct?
<kenaryn>
There're 3 occurences of 'const variable' in the docs, which is semantically insane. Wouldn'it be relevant to replace those by 'const identifier' or even 'const unit storage'?
<antaoiseach>
exit
antaoiseach has quit [Quit: leaving]
<ifreund>
woah, a lot went down while I was sleeping
<ikskuh>
ifreund: I thought the same right now
<ikskuh>
reading some syntax change github issues :D
<ikskuh>
the community was on fire!
<Xavi92>
:)
<ikskuh>
i wonder why nobody proposed "let x = 1" for mutation *laughs*
<ifreund>
honestly i'm totally fine with the more verbose `const foo = fn (bar: i32) bool {}` syntax
<ikskuh>
yeah
<daurnimator>
yeah I didn't find it the most objectionable
<ikskuh>
after reading the whole thread, i think keeping `const f = fn() u8` is totally worth it
<daurnimator>
just rules zig out for code golf ;)
<ikskuh>
daurnimator: so? :D
<ikskuh>
*grin*
<daurnimator>
if you can't win golf what sport *can* you win
<ifreund>
code golf isn't important, text editing golf is :D
<ifreund>
honestly though, this may be an "avoid local maxima" thing, i'm interested to see what comes of it and will keep an open mind
<ikskuh>
code golf is won by hq9+ by definition :D
<ifreund>
right now though i feel pretty strongly that `const f = fn () u16` makes a lot more sense
kenaryn has left #zig ["WeeChat 2.3"]
Xavi92 has quit [Ping timeout: 250 seconds]
Xavi92 has joined #zig
_Vi has joined #zig
<Xavi92>
ifreund: so do I. As I said before, this syntax makes it consistent between functions, structs and enums
<ifreund>
hmm, i think i might be beginning to come around to something like the proposed change, default immutability everywhere would be great and it does reduce visial noise
<ifreund>
perhaps `const/var everywhere` is a local maximum and the new proposal is the global one we've been waiting for
<ifreund>
super interested to see where this goes and what andrewrk decides in the end
<ifreund>
this is a big change for sure, but it's *very* worth getting right even if it does cause a lot of churn
<ikskuh>
ifreund, i don't think it will increase readability though
<ikskuh>
imagine this:
<ikskuh>
struct { foo : i32, bar = 10; }
<ifreund>
ikskuh: i don't think that syntax would be accepted for that reason, there have been many differing proposals of how exactly the new declaration syntax would work
<ikskuh>
yeah
<ikskuh>
and honestly i don't think any of them is more readable without having to explain it first
<ifreund>
all i'm saying is that we should keep an open mind and not let attachment to the status quo syntax influence our opinions
<ikskuh>
yeah
<ikskuh>
but i'm struggling with coming up with a better idea than status quo
<ikskuh>
i posted it in discord earlier, but using operator semantics is a bad idea in general
<ikskuh>
pascal: := assigns a variable, <= is less-equal, = compares for equality, == is a syntax error
<ikskuh>
vhdl: := assigns a variable, <= assigns a signal, = compares for equality, == is a syntax error
<ikskuh>
go: := declares a constant, <= is less-equal, = assigns a variable, == compares for equality
<ikskuh>
c/c++: := is a syntax error, <= is less-equal, = assigns a variable, == compares for equality
<ikskuh>
it really depends on what context you come from on how you interpret your operators
<ikskuh>
so having a keyword is definitly the better option
<ikskuh>
maybe something like pub/pri instead of "pub const" and "const" would be an option for global scope
<ikskuh>
i really don't like "set" being a keyword, this is such a common function name
<Xavi92>
ifreund: private should be implicit IMO. Similarly to default immutability, it is also safer to assume the most restrictive case here, and only specify 'pub' when needed
<Snetry>
Well this doesn't seem good `Unrecognized glibc version: 2.31.9000'
xackus has joined #zig
<betawaffle>
uhh, is the name `merge_anal_dumps` supposed to be a joke?
<xackus>
anal = analysis
<betawaffle>
i know, but still
dimenus has joined #zig
<ikskuh>
betawaffle: i giggle every time i read that :D
<fengb>
Unleash your inner 12 year old
<ikskuh>
yiss!
<ifreund>
reminds me of the blood analysis bionic in CDDA which has the id `bio_blood_anal` of course
tane has joined #zig
tane has quit [Quit: Leaving]
<Xavi92>
betawaffle: sounds like the name of a brutal death metal band
decentpenguin has joined #zig
decentpenguin has quit [Client Quit]
Xavi92 has quit [Remote host closed the connection]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
<Cadey>
ikskuh: `:=` in go creates a variable, it doesn't create a constant
<pixelherodev>
It's amazing how much work you can get done when you don't have access to your compiler :P
<pixelherodev>
Implemented about half the ISA in thirty minutes because I didn't have the option of testing every minor tweak
<ikskuh>
Cadey, oh thanks. but same difference in the end
<ikskuh>
pixelherodev: lul
<Cadey>
constants are immutable at runtime, variables are mutable at runtime
<fengb>
And it'll take 5 hours to debug now because nothing actually works? >_>
oats has quit [Quit: until later, my friends]
oats has joined #zig
xackus_ has joined #zig
decentpenguin has joined #zig
xackus has quit [Ping timeout: 265 seconds]
xackus__ has joined #zig
TheLemonMan has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
v64 has joined #zig
cole-h has joined #zig
<fengb>
“That was an impressive flood of pent-up bikeshedding” he’s not wrong :P
dimenus has quit [Remote host closed the connection]
dimenus has joined #zig
antaoiseach has joined #zig
foobles has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Quit: decentpenguin]
kenaryn has joined #zig
<kenaryn>
Please does the expression `dereference a pointer` means 'unwrap the value pointed to' or 'cease to track the address location'? or does it account for something else?
<ikskuh>
dereference is usually used to describe accessing the memory location stored in a pointer
<foobles>
yeah. if you have a pointer to an int, dereferencing the pointer accesses int that is refered to by the pointer
<kenaryn>
thank you both! I never fully grasp the concept of pointer until now.
<kenaryn>
grasped*
v64 has left #zig ["WeeChat 1.9.1"]
<ikskuh>
kenaryn: pointer are pretty simple in what they are
<pixelherodev>
There a way to have std.testing return an error code instead of panicking?
<pixelherodev>
I wanted to use errdefer to print a message on test failure
<pixelherodev>
Nope.
<pixelherodev>
Drats
<pixelherodev>
Going to have to do a custom solution then
<ikskuh>
kenaryn: give me a minute, i'll make a nice explanation :)
<kenaryn>
You're kind!
<fengb>
Back in my day, we only had peek and poke 🦖
<fengb>
Ints everywhere!
<kenaryn>
In fact, I always thought 'deferencing something' was undesirable behaviour leading to memory leaks.
<ifreund>
a pointer is just a type that stores memory addresses
<pixelherodev>
Pedancy:
<pixelherodev>
A pointer is just a number
<ifreund>
these memory address happen to "point" to other variables usually
<fengb>
Dereferencing hanging pointers and malformed pointers leads to security bugs
<pixelherodev>
A pointer *type* is just a type that stores a memory address
<fengb>
But it's not the dereference or pointer that causes it. It's a bad pointer value
<ifreund>
pixelherodev: ok yeeees but that's pretty pedantic :D
<shakesoda>
I think it's an important point though
<shakesoda>
never to forget that types are a lie and memory is just bytes ;)
<pixelherodev>
ifreund, like I said, pedancy
<pixelherodev>
`<shakesoda> never to forget that types are a lie and memory is just bytes ;)` Seconded.
<ifreund>
wise words :D
<antaoiseach>
tell that to the haskell guys! :D
<shakesoda>
I like to describe pointers to people unfamiliar as bookmarks
<fengb>
At the end of the day, it's all bits
<fengb>
So we might as well switch to 0s and 1s for everything
<shakesoda>
types may be a lie but they are a useful lie for our mortal minds
<kenaryn>
ifreund, when you said 'usually', does it imply that pointers can point to another kind of symbols? like a trait, a pragma, or even a function? or it just pointless? (i.e. useless).
<ikskuh>
<pixelherodev> A pointer is just a number
<ikskuh>
this is pretty much true
<kenaryn>
lol
<kenaryn>
nice one. Ready for the official doc!
<ikskuh>
my image doesn't even use data types for exactly that reason
<ifreund>
kenaryn: they can be danling and point to uninitialized memory if you screw up :D
<fengb>
Anything in a computer is just a number 🙃
<ifreund>
and yeah function pointers are a thing, functions are types
<fengb>
Technically true but functionally useless, just like my life
<ikskuh>
fengb: but in the end it boils down to this
<ikskuh>
everything we see, use and hear coming from a computer is just a huge amount of plain numbers :D
<ikskuh>
kenaryn: on my example: I have four variables here: ptr_a, ptr_b, struct_a and struct_b
<fengb>
There’s also translating into the analog world
<shakesoda>
storing offsets in pointer types isn't that unusual
<fengb>
One day we can directly consume digital information. One day...
<shakesoda>
and those don't directly point to anything
<ikskuh>
as you can see, each struct holds three values in our memory and the pointers both hold a single value
<fengb>
Array indexes are equivalent to pointer offsets
<fengb>
Which is why C got so brain dead >_>
<shakesoda>
fengb: this is one of the things I actually like about C
<shakesoda>
the sheer simplicity of that
<ikskuh>
but we can access the structs through the pointers: we look up the address of the pointer (this is done by the compiler), then we read the memory from this address (&ptr_a = 3) then read that memory (yields 10) and we can now access memory address 10 (which is where struct_a is in memor)
<shakesoda>
but it is an improvement to be able to express more specifically what is pointed to
<fengb>
It’s simpler for the computer yeah. But it’s semantically opposed to how people think about things
<fengb>
Like passing arrays implicitly passes the pointer instead
<fengb>
But it doesn’t do it for structs
<shakesoda>
I don't specifically agree but I'm practically disqualified
<kenaryn>
nice sheet ikskuh thank you for your time :)
<fengb>
Or maybe it’s the other way around that’s the problem. Treating any pointer as indexable >_>
<shakesoda>
fengb: it should be :D
<shakesoda>
you can't tell me what to do! i'll scan all the ram i feel like!
<foobles>
i just proposed yet another syntax for removing const :P
<shakesoda>
smh
<fengb>
My point is, I like that Zig distinguishes single and multi pointers, even if they’re the same number :P
<shakesoda>
fengb: my mental model is far too computery by now maybe
<ifreund>
yeah zig pointer are amazing
<ifreund>
s/ter/ters/
<kenaryn>
ikskuh, is the value 10 is a readable information for the end user (i.e. the programmer) or it is a "result location"? I'm not sure to follow.
tdeo has quit [Remote host closed the connection]
<ikskuh>
yes, it's readable
<kenaryn>
my bad, didn't see your last explanation
<ikskuh>
ptr_a = @intToPtr(*StructType, 10);
<ikskuh>
would create the same pointer as well :)
tdeo has joined #zig
<kenaryn>
i'm subject to overhead overflow
<kenaryn>
but the analysis cognitive semantic didn't catch it :D
dddddd has quit [Ping timeout: 250 seconds]
<ikskuh>
foobles: you're user00e00?
<foobles>
ikskuh i am `theInkSquid`
<ikskuh>
ah!
<kenaryn>
Maybe he's a Nim guy who doesn't dare to admit he has switched towards Zig since Andrew told to his github community that they henceforth compile with `zig cc` :p
<ikskuh>
i'm not sure if zig really needs destructuring
<kenaryn>
theInkSquid? he's the buddy who hide his face in a black hood on his picture?
<ikskuh>
i decided against it most of the time when i could've used it because it's clear when you write the code, but not that much anymore if you change code later
<kenaryn>
lol what is the anime's name already? isn't that Evangelion ?
<fengb>
Yeah I’m not a big fan of destructuring
<foobles>
I actually haven't seen it, I picked the image because it was used as cover art for an Internet Club album. I think the anime is Mobile Suit Gundam
<fengb>
But I also don’t like aliasing in general. Full namespaces for me!
<kenaryn>
exactly, thanks for remembering.
<kenaryn>
Agreed, aliasing defeat the purpose of `Only one obvious ways to do things` and we end up with a coding guideline style for each programmer.
<antaoiseach>
kenaryn: I tried liking Nim, but the language was madness beyond the basics... couldn't make much sense of metaprogramming
<companion_cube>
macros are for advanced use, right?
<antaoiseach>
I am a Zig newbie and I quite like Zig - I just hope the language manages to remain as simple as possible with as less magic as possible - explicitness is always nice
<antaoiseach>
companion_cube: yes, I suppose so
<kenaryn>
Yes something verbosity is for the greater good.
<kenaryn>
sometimes*
<shakesoda>
full namespaces everywhere just makes code needlessly long
<shakesoda>
sometimes by a disgusting amount
<antaoiseach>
nothing better than Common Lisp's metaprogramming for me personally... smooth as butter
<companion_cube>
except CL isn't typed… 🤷
<fengb>
I don’t agree it’s needless
<shakesoda>
now sure how that came up here though
<companion_cube>
anyway so far I like nim
<antaoiseach>
companion_cube: hahaha, yeah, that's why its metaprogramming is so flexible!
<kenaryn>
Do you have Nim full-time jobs offers in Canada?
<shakesoda>
bold of you to assume full time jobs still exist
<kenaryn>
or is it considered too "exotic" like in west europe
<antaoiseach>
companion_cube: I worked through the Nim tutorials a year back (or so) - part was great... part 2 is when I quit
<kenaryn>
yeah boldness shall be added to zig zen.
<antaoiseach>
bold concurrency?
<antaoiseach>
Hahaha... just kidding
<companion_cube>
antaoiseach: you don't have to learn everything at once though :D
<antaoiseach>
companion_cube: that's true.. I had even bought dom96's book... maybe someday again
<antaoiseach>
btw, do we have a bot that compiles Zig code here? I remember the Haskell IRC had a bot like that...?
<TheLemonMan>
kenaryn, status.im has a team of Nim programmers
<TheLemonMan>
Nim metaprogramming is the absolute bomb
urluck has quit [Remote host closed the connection]
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
<dom96>
antaoiseach, what in part 2 made you quit? :)
<antaoiseach>
dom96: It was a year ago so can't give specifics, but the whole metaprogramming bit (I'm referring to the official tutorial, of course) just went over my head...
<shakesoda>
metaprogramming stuff frequently has that problem as a whole
<antaoiseach>
Maybe it's just me! :D
* shakesoda
tends to think of it as the enemy of software simplicity
<shakesoda>
(along with the other enemy: oop)
<companion_cube>
sometimes it can make code simpler, if you use codegen for openapi or parsers or the likes
urluck has joined #zig
<shakesoda>
metaprogramming helping anything is the edge case
<shakesoda>
not to be confused with me having problems with a language having good tools for it
<companion_cube>
every language with metaprogramming has warnings that say "only reach for that if you don't have a choice" :D
<shakesoda>
and people reach for it when they DO have a choice :(
<shakesoda>
maybe I should take a harder stance on this
<shakesoda>
just say no!
<companion_cube>
yeah but people abuse all available things
<ifreund>
i tend to agree with shakesoda
<ifreund>
when you have to write code to write your code for you, you're shit is too complex
<ifreund>
s/you're/your
<shakesoda>
you also no longer have any idea how much code you truly have
<shakesoda>
won't someone please think of the compile times
waleee-cl has joined #zig
<shakesoda>
current project I'm on at work certainly did not think of the compile times, so a lot of my time is spent just waiting around for the damn thing to build
<shakesoda>
& this is a direct result of opting for designs far less simple than they could be
<shakesoda>
complaining aside, anyone doing ludum dare (maybe even with zig)?
<fengb>
My first job we had some amazing idea to do code generation in Java
<companion_cube>
what if you generate bindings to other projects?
<fengb>
So the project ended up generating code to half compile to generate more code
<shakesoda>
companion_cube: I'm all for writing code generators that spit out a file once and you just use it.
<fengb>
It took hours to setup the dev machine
<shakesoda>
doing that stuff at build time on the other hand *decimates* build times and i hate it
<companion_cube>
if you commit the generated code, yeah
<shakesoda>
i had this problem with the opengl bindings with rust
<companion_cube>
well it's that or not having bindings…
<shakesoda>
they're build time generated from the specs or some crap and it adds +30 seconds to even touch anything that comes near GL
<shakesoda>
which was a cost so unacceptable that I scrapped the project and brought in my C library to do all that stuff
wootehfoot has quit [Ping timeout: 256 seconds]
<companion_cube>
probably from the xml description of the API
<shakesoda>
I'm all for one-time code generation though, I have written a few of those to do things like generate my haxe bindings (for love and lovr)
<companion_cube>
and then you edit the generated code?
<shakesoda>
yeah
<companion_cube>
kind of makes sense I guess :D
<dom96>
There is a fine balance between too much complexity and too little
<dom96>
Go is far too little
<dom96>
Rust just on the edge of too much
<shakesoda>
too little is the side I'd rather be on, because it's a lot easier to deal with.
<dom96>
Not sure where Zig stands, but Nim is pretty perfect in the middle for me :)
<shakesoda>
too much makes things utterly incomprehensible (and ***slow***)
<shakesoda>
nim isn't my flavor but not for any kind of technical reasons
dermetfan has quit [Ping timeout: 272 seconds]
<shakesoda>
it's just not my flavor in the same way python isn't
klltkr has joined #zig
<foobles>
alright here is another proposal
<foobles>
good god
<foobles>
6 hours of my life...
* shakesoda
really just wants 1717 and the status quo otherwise...
<fengb>
Same lol
<TheLemonMan>
too many proposals and not enough code
<shakesoda>
the sheer level of activity on the proposals right now should be enough reason for pause
<shakesoda>
foobles: I actually like the .= proposal (as much as I'll like any of them in that thread...), it seems the simplest one
<fengb>
I don’t like .= because it makes field assignments look different from variable reassignment
<shakesoda>
damn you, multiple assign proposal
<fengb>
Unless it’s .= everywhere in which case I’m really not liking it >_>
<shakesoda>
I like it in the sense of "I hate it the least"
<mikdusan>
yeah multiple assign is the pita
<mikdusan>
one suggestion was that it only be used during decl
<shakesoda>
also I really don't even want multiple declaration to exist for any case other than destructuring a tuple
<shakesoda>
multiple declaration/assignment hurts legibility severely in basically all cases other than destructure and multireturn D:
<fengb>
How about === for declaration? 🙃
<shakesoda>
I've been removing code like that constantly over in this c++ mess
antaoiseach has left #zig [#zig]
shodan45 has joined #zig
layneson has joined #zig
vlad9 has joined #zig
klltkr has quit [Read error: Connection reset by peer]
<TheLemonMan>
no, it's a boolean that's only set when you `zig test` something
<kenaryn>
Ah allright, thanks for the explanation.
wootehfoot has joined #zig
<kenaryn>
When a void value is returned, does the semantic analyser compute something? (i.e. use time and/or space), or does it deal with it like a human mind? (i.e. doing nothing).
<vlad9>
I'm trying to build tetris on mac and getting this error: `unable to create target: 'Unable to find target for this triple (no targets are registered)'`; any pointers how to fix this?
<vlad9>
I'm guessing my target is `x86_64-apple-darwin18.2.0`; how do I register it?
wootehfoot has quit [Ping timeout: 250 seconds]
darithorn has joined #zig
<andrewrk>
vlad9, I'm not able to reproduce this issue
darithorn has left #zig [#zig]
darithorn has joined #zig
darithorn has left #zig [#zig]
<andrewrk>
let's figure out what is different on your system than mine
omglasers2 has quit [Read error: Connection reset by peer]
<mikdusan>
s/apple/macosx
<mikdusan>
err not this is a clang target?
_Vi has quit [Ping timeout: 272 seconds]
<andrewrk>
ok I have reproduced this issue. Homebrew has modified the default configuration llvm/clang to disable targets. Zig cannot use it as a dependency
<mikdusan>
wow that is a build option?
<mikdusan>
oh sorry you mean actual targets
<companion_cube>
andrewrk: so what's your next target? :)
<vlad9>
andrewrk: is it possible to configure clang somehow?
<andrewrk>
homebrew zig package is fundamentally broken. homebrew has to be convinced to change their llvm/clang package
<TheLemonMan>
maaaaybe we should call LLVMInitializeAllTargetInfos and friends?
<andrewrk>
we do that for zig code. but why should we call that before calling clang's main() ?
<foobles>
andrewrk going back to last night's discussion, do you really think it's a good thing to have mixed assignment/declaration in the same statement? I think that would be a monster to read in some cases, and it would just be better to declare a temp variable and assign on the next line.
<foobles>
I have a new proposed syntax too, for the last comment on #576
<andrewrk>
the only point of multiple assign is to avoid declare and assign on separate lines
<foobles>
whats wrong with doing that?
<andrewrk>
TheLemonMan, it doesn't solve the problem, just tested it
<andrewrk>
I have a feeling this is some more B.S. having to do with c++ static initializers
<foobles>
I think it would be easier to learn, for multi-assign to be all-initialization or all-assignment
<andrewrk>
foobles, because it involves a variable + undefined instead of a constant
<TheLemonMan>
just declare osx as a whole as a tier4 platform and be done with it heh
<foobles>
andrewrk not necessarily, look at this example
<foobles>
wait i didnt mean to hit enter
<andrewrk>
TheLemonMan, I'm working on a stage2 IR proposal / first passing test case. hopefully will have that available for you to provide some feedback on within a few days
<pixelherodev>
Stage2 IR stuffs?!
<andrewrk>
oh yeah, pixelherodev is going to be all over this too
<TheLemonMan>
andrewrk, the DIEnumerator patch got approved, thanks for pushing the llvm devs to review it
<andrewrk>
thanks for the patch. glad to hear it's going in
<foobles>
mikdusan my only gripe with using `:=` for reassignment, is that `:` currently is only used in declarations. My syntax does propose taking the `:` out of type-specifiers, but I feel like there is already a precedent for `:` being used with declarations only (variables/members/parameters)
<foobles>
so I think `=` should be reassignment, even though it is less common
<fengb>
Are we planning on keeping = for field assignment?
<foobles>
that I what I think
<foobles>
because they are declared in the struct
<fengb>
I think it makes sense for field assignment to match var reassignment
<fengb>
And at that point, it's not apparent to me that declarations would be more common
<foobles>
so field default should use `:=`, but field assignment/initialization should use `=`, since the member is already declared in the struct
<foobles>
yeah
<andrewrk>
I wonder if I would get murdered if I simply removed reassignment syntax entirely
<andrewrk>
(&x).* = new_value;
<fengb>
I'm actually fine with that
<andrewrk>
I thought you wanted to see `const` in front of const decls
<mikdusan>
the main crash with `:=` was multi-lhs. so solving multi-lhs with making it "uniform" (no mixing) pretty much removes the sole reason andrew vetoed `:=`... I guess my last gist could just as easily be `:=` for decl, and leave `=` to always mean assign
klltkr has quit [Ping timeout: 256 seconds]
<andrewrk>
I think foobles's latest suggestion to simply disallow anything but const decls for multi-assignment recovers the viability of :=
<fengb>
I like status quo the most, but I mostly want to keep declarations greppable
<fengb>
And scannable
<andrewrk>
declarations are even more greppable with dropping const: search for `foo =`
<fengb>
But it'll also be mixed with reassignment with the current semantics
<foobles>
true, but with `:=` you could just search for `:=` :)
<fengb>
And needing to follow context to understand the difference isn't great
<andrewrk>
since the whole point of multi assign is to avoid `var` and `undefined`, it's reasonable to restrict it to only const decls
<companion_cube>
wait, what's := about? is this becoming Go? :s
<foobles>
I think it would be pretty nice to read and write
<TheLemonMan>
companion_cube, or ocaml's ref :)
<foobles>
also even though declaration is more common, a bigger operator for it makes it easier to scan for with your eyes
<companion_cube>
yeah well, not the best part of the language
<companion_cube>
`.x i32 := some_default` waaaa
<companion_cube>
getting further from ML :(((
<BaroqueLarouche>
we should rather use :: than := if we want to go that route
<companion_cube>
good modern grammars prefix declarations with something…
<companion_cube>
a = 1 is python
<TheLemonMan>
what's wrong with the status quo?
<mikdusan>
foobles: one thing if we don't invert. that is, if `:=` is used for decl... `var i: u32 = 10;` or `var i: u32 := 10;` . the former makes search/scan less obvious. the latter lots of `:`
<foobles>
mikdusan did you read my proposal? I suggest getting rid of `:` for type specifiers
<companion_cube>
please don't
<foobles>
so it would be `var i i32 := 10;`
<foobles>
i think thats fine
<andrewrk>
TheLemonMan, how do you feel about using `const foo = fn ...` for every function with #1717 ?
<companion_cube>
why is 1717 such a big deal anyway? :/
lunamn has joined #zig
<andrewrk>
status quo is viable. just to be clear
<foobles>
because now almost every single thing at global scope will be prefixed with const, decreasing readability imo
<foobles>
its just noise
<companion_cube>
imho status quo is 10,000× better than this Go-like stuff
<companion_cube>
foobles: not noise, it clearly shows where declarations are
<TheLemonMan>
andrewrk, eh I don't really mind
<torque>
I don't think that declarations being prefixed is "noise"
<andrewrk>
TheLemonMan, that's good to know. one thing I learned from this hot topic is that many people are happy with status quo, even given extra typing for function decl syntax
<companion_cube>
(`let` at toplevel might be shorter than const, as someone points out in the issue)
<fengb>
Let's have a 1 character wide keyword. How about 💩
<companion_cube>
`let f = fn() …` is ok I guess
<mikdusan>
foobles: yes I see it now
<torque>
I am still boggled by people seeming to care about number of keystrokes
<torque>
if we really wanted to minimize keystrokes, all variable names would be 1 letter long
<fengb>
One thing that I would like is making const easier to declare
<companion_cube>
cst x = 1
<foobles>
keystrokes arent the matter for me, its visual noise. almost everything at top-level will be easily discernable even without the word `const`, and so I think `const` becomes noise
<companion_cube>
foobles: `const x = …` makes it regular and clear that this declares `x`
<companion_cube>
same for `var x = …`
<andrewrk>
const is clearly noise at the global scope. but it's a given that the syntax for decls will be the same in global and local scopes
<companion_cube>
just having `x = …` makes it less clear if it's assignment or declaration (die, python, die)
<andrewrk>
I think foobles understands the tradeoffs at stake
<andrewrk>
I'm curious if torque and fengb would consider := to adequately denote const decls
<torque>
If the goal is to force programmer behavior through language expression, I think rust's approach of forcing mutable variables to have an additional keyword is the way to go, though `const var` probably isn't going to work for us
<companion_cube>
I find it not regular to have some declarations be keyword free, though
<fengb>
I didn't like := at first but it's grown on me. At the very least, it's sufficiently different from =
<fengb>
And it
<fengb>
it offers an easier path towards const, which I'm generally in favor
<companion_cube>
why not `let` then?
<mikdusan>
ahhhh
<foobles>
`let` was rejected long ago
<foobles>
apparently
<torque>
I'm generally not a fan of adding new symbols to the language and I prefer a prefix keyword (I think I'd consider := to be noisier than `const`, since my brain primarily reads english, not bizarre punctuation constructs)
<fengb>
Just saying in general, I like const the most but := is okay too
<andrewrk>
let is not better than const, it's the same or worse
<companion_cube>
it's as short as var
<torque>
well, if the argument is that "const is harder to type than var", that's not true
<shakesoda>
it's only better if your interest is saving a few characters
<andrewrk>
saving a few characters is not the point
<fengb>
shakesoda: unfortunately some people default to var *cough* Tetralux *cough*
<hryx>
Just catching up. That idea of restricting a destructure to either declare or reassign (not mixing) seems smart. I dunno when one would want to mix those
<fengb>
Which removing the const keyword might convince them to const by default
<torque>
I don't think a language should bend to try to fix one person's sloppy code
<fengb>
hryx: Go does it really often, but it's also a byproduct of its design >_>
<foobles>
yeah, we have error unions
<companion_cube>
Go's syntax is truly awful, though 🤷
<andrewrk>
zig's design is 100% benst around making it harder to write sloppy code
<andrewrk>
wow look at me turn that "bent" into a "const"
<fengb>
I think if a language can offer saner defaults that aren't too intrusive, we should consider them
<hryx>
fengb: in Go, that has actually caused me bugs
<torque>
I mean, it's kind of weird seeing this discussion so immediately after the "pass pointers const by default" was rejected so decisively
<andrewrk>
the two are related
<companion_cube>
(ah, there's also "val" if you feel like writing scala)
<torque>
yes, I agree, but the bigger thing is that it seems like the arguments in favor are essentially the same
<fengb>
Let's make all constants be prefixed with k 🙃
<andrewrk>
I want to note that zig does create local automatic temporaries on behalf of the programmer. plenty of expressions will have hidden *stack* memory allocation
dermetfan has quit [Ping timeout: 272 seconds]
<companion_cube>
I mean, as soon as you write `f(g(x))` it happens, right?
<andrewrk>
yes depending on the type of g(x)
<companion_cube>
I don't think it's really related to syntax issue
<andrewrk>
creating a named constant local declaration is one of the safest, cleanest, most readable things you can do
<andrewrk>
I like that `a = b;` as a const decl rewards this
<companion_cube>
and it should be clearly indicated with a keyword 🤷
<andrewrk>
zero syntax overhead
<companion_cube>
a = b; means assignment in 99% of languages :/
<torque>
<andrewrk> zig's design is 100% benst around making it harder to write sloppy code <-- I disagree with this to a certain extent. I think if you do this, you end up with rust. at a language level zig does not try to remove the ability for the programmer to make memory or concurrency-related mistakes
<shakesoda>
not being able to actually identify decls based on furthest left is not good
<companion_cube>
^
<foobles>
andrewrk thats why I feel that `:=` is a happy medium for declaration. It's big enough to be disinct from reassignment, and also sort of pops out to the eye
<foobles>
and it has precedent
<companion_cube>
well, ugly precedent
<companion_cube>
:)
<andrewrk>
torque, on the other hand, the borrow checker can force a programmer down a path of unnecessary heap allocation / reference counting to make the compiler happy, whereas zig programmers are free to pursue more resource-optimal code
<shakesoda>
torque: rust takes it to an obsessive extreme
<torque>
now there's arguably a threshold for "reasonable problems to mitigate" and I think zig has so far struck a happy medium there
<companion_cube>
not that obsessive, they have `unsafe`
<shakesoda>
which itself is obsessive
<karrick>
One of the frustrating things about Go to newcomers is the subtle differences between using `var foo int; foo = 3;` and `foo := 3;`
<torque>
If I were absolutely forced to make a decision, I would definitely take `:=` over having to use a keyword to perform normal (re)assignment
<shakesoda>
i'd be okay with `:=`
<karrick>
it is pretty straightforward, but in golang slack, lots of golang newbies struggle with understanding when each could be used.
<shakesoda>
but I don't like it
<companion_cube>
I'd rather pick the status quo, tbh
<shakesoda>
me too.
<companion_cube>
not having `a = b;` be an assignment will alienate all these C programmers :D
<companion_cube>
(and java, and C++, and…)
<andrewrk>
we have a lot of votes for status quo, which I will remind everyone still remains the null hypothesis
<fengb>
They're already pissed off that we have backwards type signatures >_>
<companion_cube>
yeah but they know they're wrong on that one, function pointer types are known to suck
<companion_cube>
(and it blends better with type inference)
<torque>
But I'm still trying to wrap my head around the actual high-level goal here: is it increased use of `const` to reduce problems associated with mutability? is it reduced use of `const` to remove line noise of the code (which I think is a very subjective claim)?
<ifreund>
status quo or `:=` both seem like good options to me, I'm really not a fan of the new keyword to reassign though
<foobles>
My proposal still uses `=` for reassign
<shakesoda>
backwards types have all kinds of nice properties about them
<foobles>
i agree, a keyword for reassign is bad
<companion_cube>
shakesoda: they're forward, not backward ;)
<shakesoda>
and they're good for consistency, etc
<shakesoda>
companion_cube: relative backward :)
<andrewrk>
ifreund, at this point I'm even more a fan of requiring `(&x).* = new_value;` than a new keyword for reassigning
<companion_cube>
:D
<ifreund>
:D
<shakesoda>
I'm used to zig's type syntax anyways, I write a lot of haxe
<companion_cube>
so I guess we're safe on this one
<andrewrk>
"why is reassignment so awkward?" "why are you reassigning stuff?"
<fengb>
How about a new mutation postfix operator
<fengb>
x.! = value
<andrewrk>
you're like 18 hours behind in the issue comments
<ifreund>
please no
<shakesoda>
why reassigning? perhaps because i'm programming
<shakesoda>
:D
<fengb>
Doh
<torque>
why is reassignment suddenly The Great Evil
<fengb>
There's a million comments
<ifreund>
it means your code is too complex
<andrewrk>
because it's between the rock and the hard place
<companion_cube>
wow, so we won't have loops anymore? :D
<fengb>
I feel like I miss half an hour and I can't catch up
<ifreund>
you should be able to do everything without reassignments if you're big brained enough
<karrick>
Is there a GitHub issue discussing this issue so I can see the thing being resolved?
<torque>
the SNR in the github issue is about the same as it is here
<karrick>
gracias
<andrewrk>
I recommend to read SpexGuy's summaries and nothing else
<ifreund>
^
<ifreund>
SpexGuy rules
<pixelherodev>
I'm guessing there's no way to specify a slice's *minimum* offset? :P
<pixelherodev>
As an optimization for emulated ROM access, I'm subtracting the virtual base from the pointer
<pixelherodev>
So that e.g. `buffer[0xFFFE0000]` gives the first byte
<pixelherodev>
Except that's, quite reasonably, out of bounds
<shakesoda>
clear solution to all kinds of syntax concerns, just remove all rmw operators
<shakesoda>
goodbye, +=!
<pixelherodev>
Eh, I'll just up length by 0xFFFE0000 as well
<pixelherodev>
That's a brilliant solution.
<foobles>
i remember you saying you liked lua :P
<shakesoda>
let the lua flow through you
<pixelherodev>
Oh wait, just turn it to a normal pointer-to-unknown
<shakesoda>
lacking rmw operators is both a nice simplification and an annoying and error prone inconvenience in lua
<companion_cube>
btw lua has `local` which is also super long :D
<shakesoda>
zig also has local, to be sure
<shakesoda>
it just means something completely different
<companion_cube>
I mena, in lua, `local` should be the default, right? but it's verbose
<mikdusan>
foobles: this one is `:=` back for decls (I left `:` for type spec.. it actually doesn't bug me). imo `:=` is pretty easy to parse for decls:
<shakesoda>
that sounds like code I'd gaze upon in horror before refactoring to not do that
<shakesoda>
or in high volume I'd just cut my losses and jump ship from
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<Snektron>
nothing like putting `template <typename A, typename B> A operator,(A a, B b) {return a;}` in someones code
<shakesoda>
Snektron: I might actually consider no longer working with someone over a few instances of that
<karrick>
FWIW, when I do some JavaScript programming, I do something very similar to this expression on #1717: `pub const main = fn() void {` and I quite like it.
<shakesoda>
as nothing good can come of it
<shakesoda>
karrick: yeah, I use the form a fair bit in lua.
<Snektron>
i'd also like to point out that defining functions as `name =` makes it really easy to find a declaration with grep
<foobles>
yeah
<foobles>
here is an example translated to the syntax suggested in my proposal:
<companion_cube>
almost at `public static void main`!
<karrick>
What I do not get is how in some of the structure examples I have seen, properties are declared with colon syntax, but methods are bound using an equal sign in the same structure declaration.
<shakesoda>
foobles: and as for vars?
<karrick>
companion_cube: yeah, that's what I thought too... /shrug
<companion_cube>
:D
<foobles>
karrick that is because defaults are put with the _declaration of the member_, so they should use `:=`, while field initialization is external to the declaration, meaning `=` should be used
<foobles>
shakesoda `var x := y;` is my goto
<fengb>
We could replace the pub keyword with exposing anything starting with a capital letter 🙃
<foobles>
NO
<foobles>
GO GOT THAT WRONG
<companion_cube>
go got everything wrong :p
factormystic has quit [Ping timeout: 265 seconds]
<karrick>
such hatred... ;)
<shakesoda>
foobles: ok
<pixelherodev>
Gah
<companion_cube>
well they NIH'd some parts uselessly (like the syntax), and stayed in 1970 for other things ;)
<pixelherodev>
Where's the default Zig linker script??
<andrewrk>
pixelherodev, I've been meaning to figure that out. I think that is currently determined by LLD's code
<pixelherodev>
Noooooo
<pixelherodev>
:(
<pixelherodev>
Trying to adjust it for
<pixelherodev>
uh
<pixelherodev>
totally legitimate reasons
* ikskuh
nods
<pixelherodev>
Definitely not trying to map the entire 32-bit address space
<pixelherodev>
So we use the default LLVM one?
<pixelherodev>
Idea!
<pixelherodev>
`find / -name \*.ld 2>/dev/null`
<pixelherodev>
Nothing. (nothing relevant at least)
_Vi has joined #zig
<ikskuh>
pixelherodev: pacman -Ql llvm
ur5us has joined #zig
<pixelherodev>
Not on arch
* pixelherodev
rolls eyes
<ikskuh>
damn
<companion_cube>
:DDD worth a try
<ifreund>
who else isn't on arch, raise your hands
<Xavi92>
ikskuh: so there seems to be two main approaches: one based on new operators (`:=` and `.=`) and one based on changing existing keywords
<ikskuh>
yeah
<Xavi92>
ikskuh: hrm. If I haid to say my opinion on this, I'm more for keywords than operators.
<Xavi92>
Operators add a barrier for newcomers IMO, more than keywords
<Xavi92>
For example, GNU Make is all about operators and is often considered very cryptic
<companion_cube>
Xavi92: and one based on keeping the current state of things
<Xavi92>
companion_cube: status quo much likely means default immutability won't be achieved
<ikskuh>
Xavi92: why? there's a proposal that will enforce immutability when not needed
<shakesoda>
operators tend to make things cryptic
<shakesoda>
i'd like to avoid cryptic
<shakesoda>
as i think most of us would
<Xavi92>
shakesoda: I think so too
<Xavi92>
companion_cube: from all that has been discussed, as long as the `const` keyword is there, pointers and arrays will be kept mutable by default to avoid things like `*const *const Foo`
<Xavi92>
ikskuh *
<companion_cube>
🤷
<Xavi92>
ikskuh: Or that's what I read yesterday, but since so many things have been discussed recently, that might have changed already
<ikskuh>
<Xavi92> After all, functions inside structs are also struct fields, aren't they?
<ikskuh>
<companion_cube> they're comptime fields, I think?
<ikskuh>
no, they are struct members
<foobles>
in the compiler, should I refer to `?T` as an "option" or an "optional"?
<foobles>
just for consistency's sake
<Xavi92>
ikskuh: exactly, so they (at least) have the `.` prefix, if it had to
<Xavi92>
ikskuh: Using it only for variables looks a bit inconsistent IMHO
<hryx>
andrewrk: thanks, I will see about revising that tonight or tomorrow
<companion_cube>
ikskuh: but they're not fields at runtime
<hryx>
1717 needs a refresh anyway. it's so old that it uses the pre-PEG grammar
<Xavi92>
BTW, if multiassign is complicating language design, why not just get rid of it? There are several other ways to achieve multiassign
<foobles>
yeah im not a fan of multiassign in the first place
<companion_cube>
rust does it well, btw: `let (mut x, y) = …;`
<foobles>
yeah
<companion_cube>
(destructuring with multiple bindings)
<companion_cube>
gotta say rust picked it syntax pretty well 🤷
<companion_cube>
at least for expressions
<foobles>
and its just a natural result of a big emphasis in pattern matching syntax
<foobles>
yeah
<foobles>
patterns are great in rust
<companion_cube>
and sum types
<companion_cube>
(well, it's basically ML with the memory model of C)
<companion_cube>
(or C++, rather)
<Xavi92>
Would Rust's syntax for multiassign help us out in Zig?
<Xavi92>
I mean, simplify language design
<foobles>
no
<foobles>
that would probably need a completely seperate issue
<companion_cube>
it's not multiassign, it's just pattern matching
<companion_cube>
rust functions all return exactly one values
<companion_cube>
value*
<foobles>
yeah. multiple return values is just done with tuples
<foobles>
which i hope zig could do actally
<Xavi92>
Then I'd just get rid of it, unless Zig uses tuples (which I'd also prefer)
<Xavi92>
In fact, I though Zig was attempting to use tuples for this. How is it done instead?
ifreund has quit [Ping timeout: 265 seconds]
<greaser|q>
as someone who's done a fair bit of Python, i'd like to stress that making sure you can't make a tuple by accidentally having a comma on the end of a value is a worthwhile thing. sure, it's less of a problem when you've got static type checking as it tends to catch that stuff, but the fact that it's a thing in Python makes me not really able to use the language without throwing mypy at everything
greaser|q is now known as GreaseMonkey
<GreaseMonkey>
also i'm currently on 0.5.0 until void updates LLVM to version 10
<Xavi92>
Hey GreaseMonkey :)
<GreaseMonkey>
sup, started picking up the language a couple of days ago
<Xavi92>
Cool :)
<companion_cube>
well tuples are already much more explicit than in python
<GreaseMonkey>
whereas with Python tuples the only explicit language comes from the programmer ;)
<Xavi92>
THE PSX HOMEBREW SCENE SHALL INVADE ZIG. RESISTANCE IS FUTILE
<GreaseMonkey>
i'm actually looking forward to the day i can get away with using Zig at work, it's not going to be on my current project, and probably not on the next project lined up, but the project after that is probably where it'll be a good option
<companion_cube>
GreaseMonkey: 😂 indeed
<Xavi92>
GreaseMonkey: then you must be in a very open-minded company
<GreaseMonkey>
memcpy(&dst, &src, sizeof(dst)); is pretty much the one antipattern i want to see the end of
<GreaseMonkey>
i am in an open-minded company but as it stands, for embedded stuff, C is really the only option for something w/ 20KB of RAM
<Xavi92>
GreaseMonkey: Zig sounds interesting for such targets though. Which microcontrollers are you using BTW? 8051?
<Xavi92>
STM8?
<GreaseMonkey>
STM32
<GreaseMonkey>
so ARM-based
<Xavi92>
So LLVM support :)
<GreaseMonkey>
i'd love to move the thing over to Clang because i'm so sick of GCC's thumb-1 optimiser bugs
<GreaseMonkey>
but, well, i'm not sure how to get the cross-compilation stuff into Ubuntu 18.04
<Xavi92>
GreaseMonkey: oh, did you really get compiler bugs? Never happened to me on GCC
<GreaseMonkey>
GCC interprets thumb-1 as meaning "the multiplier on this chip is the slowest thing in the world"
<GreaseMonkey>
Xavi92: they're bugs in the optimiser. it'll optimise power-of-2 division just fine, but anything else and it'll defer to __aeabi_u?[il]div(mod)?
<GreaseMonkey>
instead of doing magic multiplication
<Xavi92>
Ouch
<GreaseMonkey>
also, multiplication will quite happily spew out 12 ops of shifts/adds/subs even though it's got a 1-cycle multiplier
<GreaseMonkey>
i also recall a case when i was grinding a tight loop where sometimes it'll do UXTB (good) instead of two shift ops (bad), but it's a bit arbitary as to whether it'll opt for UXTB
<GreaseMonkey>
or was it UXTH, or was it a MOV and an AND
<GreaseMonkey>
either way, GCC has issues which can result in slowdowns esp. in cases where timing is already tight. but enough about compilers that have weird issues.
<Xavi92>
GreaseMonkey: thought GCC was well-polished for ARM targets