ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
quc has joined #zig
hoppetosse has quit [Ping timeout: 264 seconds]
mahmudov has joined #zig
quc has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
quc has joined #zig
quc has quit [Remote host closed the connection]
quc has joined #zig
davr0s has joined #zig
commander has quit [Remote host closed the connection]
JinShil has joined #zig
mtn has joined #zig
v1zix has joined #zig
mtn has quit [Ping timeout: 252 seconds]
nwsharp has joined #zig
<nwsharp>
Hey. Poking away on float parsing.
<nwsharp>
What's the preferred line-limit length in the standard library code?
mahmudov has quit [Remote host closed the connection]
zolk3ri has joined #zig
<dbandstra>
hmm `_ = func();` is risky if you change a function which used to return just a regular value, so that it now can return errors... now all those calls are silently ignoring the errors
xtreak has joined #zig
dbandstra has quit [Quit: Leaving]
davr0s has joined #zig
zolk3ri has quit [Remote host closed the connection]
qazo has joined #zig
<GitHub139>
[zig] nwsharp opened pull request #1282: std.io: PeekStream and SliceStream (master...master) https://git.io/fN4lA
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xtreak has quit [Remote host closed the connection]
v1zix has joined #zig
<Triplefox[m]>
topic that came up at the meetup i went to tonight: compiler assistance with constant-time execution guarantees to prevent sidechannel attacks. it sounds interesting but also challenging to practically implement because cpu hardware isn't presently specified so tightly that it works the same everywhere
commander has joined #zig
meowray has joined #zig
xtreak has joined #zig
v1zix has quit [Quit: Page closed]
davr0s has joined #zig
xtreak has quit [Ping timeout: 256 seconds]
<unique_id>
andrewrk, I have some C++ code that looks like this: https://pastebin.com/raw/3yza1nMi - I don't know if there's anything that's as elegant as a goto here?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xtreak has joined #zig
<unique_id>
the loops are searching through a multidimensional data structure. When a condition is found, we invoke an algorithm on the data structure. There's no way to know what the algo does other than that it made progress, so we must restart our search.
<unique_id>
The algo is given the current position
<nwsharp>
I think that comes back to (about!) the only legitimate use of goto in C++ that I've come to accept these days: breaking out of multiple loop levels cleanly.
<nwsharp>
Because what you have there is basically while(1) { for(...) { for (...) { break 2; } } }
<unique_id>
right
<skyfex>
Doesn't Zig have blocks for that? blk: { .... break :blk; .... }
<skyfex>
Doesn't seem to be well documented, but there are some examples in the documentation that uses it
very-mediocre has joined #zig
<unique_id>
if the while loop in nwsharp is given a block name, then it would work
<unique_id>
as far as I can see, to use blocks, I have to introduce an additional while loop, which is fine.
<unique_id>
an while loop*, so 1 while, 2 for
<nwsharp>
Mhm. Just started Zig yesterday. Didn't notice block labeling. Good ergonomic feature.
<skyfex>
You sure? Again, the documentation is missing, but look at @compileLog example.. there's a block without a while or for loop
<unique_id>
as far as I can see, blk: { break :blk; } breaks out of the entire block, it does not go to the top
<unique_id>
it goes to the bottom, and if the block is a while/loop, then its like a continue
<nwsharp>
Yeah, you'd need the extra while loop. Which IMHO is actually better even though it's more nesting.
<skyfex>
Oh right, I didn't think it through probably
<skyfex>
*properly
<very-mediocre>
the outer while loop makes sense because what the goto would be doing is looping, imho it's more explicit which is in line with zig's style
<skyfex>
Yes, I mean, you are essentially implementing a special loop, so 'while' would make it clearer
<unique_id>
very-mediocre: it's less explicit, more confusing. Look at my last pastebin. It's not self documenting, that's for sure, and has a confusing extra break
<nwsharp>
I honestly think that looks better fwiw.
xtreak has quit [Remote host closed the connection]
<very-mediocre>
Trying to parse the pastebins, not sure they're 100% equivalent
<very-mediocre>
I'm not pro at zig, when you do `break :blk` i'm not sure if that breaks the whole while loop
hopppetosse has joined #zig
<skyfex>
Actually, I think the clearer way to implemented it is to introduce a variable.. while (!workFinished) { ... } and then break out of the outer for loop.. I think that very clearly expresses what you want to do
<very-mediocre>
but I digress, I'd say it's more explicit but less readable, so you may have a point
<very-mediocre>
since zig's priority is readability
<unique_id>
it doesn't break out of the whole loop
<nwsharp>
I don't like the induced-break-from-boolean pattern very much. It's about the only option w/o goto, though.
<very-mediocre>
ok. Looking at the docs as I haven't seen an example of while with a labeled block before
<very-mediocre>
recursion is an option here (or... it will be once they fix it)
<very-mediocre>
anyway unique_id you have a point about readability
<nwsharp>
Yeah, the docs could definitely use a bit on labeled blocks.
<nwsharp>
It's in a few examples but I think it just comes out of nowhere.
<skyfex>
There's also "for { } else { }" which could probably be used to good effect here.. have the outer for loop return a boolean which states if work is done. If you found work needed to be done, do "break :blk false" and in the else do "break :blk true"
<very-mediocre>
skyfex's `while (!workFinished)` is what I'd do intuitively tbh
<unique_id>
break :restart_work
<unique_id>
now it documents itself
<nwsharp>
I actually oftentimes write new functions that contains just the loop structure so I can use "return" to break out of all of them.
<unique_id>
i'll have a look at the for else stuff
<nwsharp>
Anyways, going to hit the sack. Will dream of breaking out of nested loops.
<skyfex>
Yeah, just using functions would be good.. nested functions would probably help, but it's not supported yet
<nwsharp>
Yeah. Once you start bringing up nested functions then closures start rearing their heads.
<very-mediocre>
tbh it looks very recursive to me
<very-mediocre>
the function should simply call itself until it terminates
<unique_id>
these things are just complicating what is really simple and probably very efficient code. It's best to use while(true) :restart_work { }, which hopefully will result in the same number of jumps in the executable
<nwsharp>
Unless you can guarantee a tail call you'd end up very unhappy if the algorithm takes a while to converge.
<very-mediocre>
True.
davr0s has joined #zig
<very-mediocre>
This function looks like it ends on a tail call though
<nwsharp>
Does zig have a mechanism to enforce a tail-call?
<very-mediocre>
Recursion is broken in zig right now
<nwsharp>
Well, there are tail-calls w/o recursion.
<nwsharp>
I honestly would be surprised if I ever noticed that recursion was broken. I almost never use it. I think it's terrible.
<very-mediocre>
True but that optimization is minor and wouldn't be felt in most cases
<nwsharp>
It's not about speed so much as it is about stack space.
<nwsharp>
And you definitely feel that in my experience.
<unique_id>
My recursion skills are rusty, but I don't think I'd ever replace 14 lines of simple looping with a recursive function
<very-mediocre>
It depends on context. If you're writing a compiler it's sometimes cleaner due to referential transparency
<nwsharp>
Especially if you're like me and you like to put lots of things on the stack to avoid malloc at all costs.
<very-mediocre>
where every function call can be considered as what it evaluates to
<nwsharp>
(I write storage appliance software for a living. Malloc can sometimes be slower than your disk!)
<nwsharp>
Now definitely going to bed.
<very-mediocre>
gn
<very-mediocre>
I might be forced to leave because Windows 10 decided it's update time
<nwsharp>
hehe
xtreak has joined #zig
JinShil has quit [Quit: Leaving]
zolk3ri has joined #zig
<unique_id>
andrewrk: This shows how bloated the Zig code looks compared to C++, primarily because of lack of c-style for loops: https://pastebin.com/raw/YJcR8gB9, but then also the extra while loop because of lack of goto. Though goto is of course going to be needed much less. Zig makes most things vastly cleaner, this code I think shows where it doesn't
<unique_id>
ive labeled the gotos inconsistently in the c++ code, but it's fine. Just an error in extracting the code out.
<skyfex>
Although I agree that the lack of C-style for loop makes Zig less clear here, I think C++ in general is a pretty good example that adding syntax to make various things "easier" can quickly make the language itself painfully bloated
<unique_id>
Absolutely. But looping is central to programming and some code bases are going to have lots of the traditional style of looping (I'm guessing), and it gets bad when you have loops inside loops.
<skyfex>
What would be better than C-style for loops is loops on ranges. There is a proposal for this, so you can chime in there:
<unique_id>
absolutely, any solution where you don't have to declare a variable outside the loop would be fine
<unique_id>
and thejoshwolfe's comment on a..b not knowing about whether it includes b, it wouldn't ever do that xD. Common we know this.
<unique_id>
because b could be len
<unique_id>
and we are 0 indexed
<Triplefox[m]>
i've dealt with translating c-style loops to simple for-iterator/while syntax in haxe many a time...it mostly showed me that for loops in c are really terse constructs that do a lot, perhaps too much
<unique_id>
all I mean when I say c-style for loops is a looping construct that does not require me to declare a variable outside of the loop
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<skyfex>
Nim's syntax is pretty great in this regard. (0..<n) is absolutely clear. The only problem is that leaves (0..n) a bit ambigous
<very-mediocre>
I fnid (0..<n) ugly
<very-mediocre>
it's too fidgety having a syntax solution rather than a simple +1
davr0s has joined #zig
<very-mediocre>
in general I'm aghast at inconsistent syntax
<very-mediocre>
< is a comparison operator, if you have it in a different context then that becomes a new operator
<very-mediocre>
I have the same gripe with zig's `while (condition) : { i += 1}`
<very-mediocre>
`:` denotes types everywhere else
<very-mediocre>
`blk:` is also somewhat intuitive as it's the English usage of `:` to denote a label
<very-mediocre>
Someone reading `while (condition) : { i += 1}` for the first time cannot understand it as it's special syntax
<very-mediocre>
imho ranges should be indexed like arrays, with a non-inclusive upper bound
<skyfex>
There's not enough characters on a standard keyboard to have both completely consistent and sufficiently large syntax if you ask me. If you want complete consistency, then it's best to go for real simplicity like Lisp or Forth
<very-mediocre>
I want reasonable consistency, of course that's subjective and everything I say is imho
<skyfex>
(but I don't like the while syntax either.. I think it should be replaced with for loop on ranges)
<unique_id>
oh common
<skyfex>
(but that introduces the problem that 0..n being exclusive is intuitive for arrays, but 0..n being inclusive is possibly more intuitive for ranges in general)
<very-mediocre>
Ranges being inclusive is a footgun if everything else in your language isn't
<unique_id>
if you remove ": (i+=1)" then you remove the usefulness of the continue statement
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<very-mediocre>
unique_id: I don't argue that it should be removed, only that the syntax is confusing
<unique_id>
no more/less confusing than c's syntax
<very-mediocre>
while (condition) : {expr} {something}
<very-mediocre>
what does the colon mean, grammatically?
<unique_id>
it's (expr)
tiehuis has joined #zig
<very-mediocre>
fair enough, it's () not {}
<very-mediocre>
but the point still stands
<skyfex>
unique_id: good point.. it is an uglyness, but maybe it's a necessary uglyness
<unique_id>
I don't find it ugly
<very-mediocre>
But then why colon in terms of grammar?
<unique_id>
who cares
<very-mediocre>
well that's where we differ, I care about symbols being intuitive
<unique_id>
the syntax is intuitive
<unique_id>
and very simple
<skyfex>
I'd say it's objectively a conceptual uglyness.. in that it's not very consistent with the rest of the language. Suddenly there's a statement that's evaluated somewhere completely different from where it is typed? Subjectively I don't find it too ugly either, but I think that's because I'm used to C style for loops
<tiehuis>
: for while is a bit of an oddball compared to all other uses of :
<very-mediocre>
andrewrk doesn't want to change it and I accept that, but I couldn't help discussing it while on the topic of consistent operators
<skyfex>
My experience is that C style for loops is not very intuitive for people learning the language, I taught C++ for a class.. it always required qui
<skyfex>
te a bit of explaining
<very-mediocre>
If I were a beginner I'd find while() : () { } more confusing
<very-mediocre>
for loop has 1 set of parentheses
<unique_id>
if c style for loops are not intuitive, then it's because these people are completely new to programming
<unique_id>
and their opinion isn't worth a dime
<skyfex>
Logically it should be "while (..) { .. } : (..)" but I realize that's less readable to experienced programmers
<skyfex>
That's why I say some uglyness can be necessary
<unique_id>
yes, and defer shouldn't exist ...
<unique_id>
or be placed somewhere completely differently..common
<very-mediocre>
I don't think defer is analogous
<very-mediocre>
for me it's the mental parsing of operators and parentheses that i find adds the most complexity to nested code
<very-mediocre>
>`<skyfex> Logically it should be "while (..) { .. } : (..)"` hence my mistake above, i recalled it that way
<skyfex>
defer is actually a pretty good example that if you're going to have a construct that moves your code somewhere else, it should be a pretty damn explicit syntax for it
<unique_id>
like a special location in a for or while loop
<unique_id>
having the post operation at the top with the condition makes the loop more declarative, it makes it way clearer what it's doing
bheads_ has joined #zig
<skyfex>
but anyway, I'm not proposing any changes.. only if for loops is generalized to the point that "while(..) : (..)" becomes redundant should it be considered at all.. but that's way in the future for the language
<unique_id>
versus having it after the loop body
<very-mediocre>
unique_id: at this point you're just reinventing the for loop, but with exotic syntax
<very-mediocre>
and i daresay, special syntax
<very-mediocre>
and more parentheses and operators than needed
bheads__ has quit [Ping timeout: 240 seconds]
<very-mediocre>
skyfex: with ranges `for` becomes pretty nice
<very-mediocre>
I wonder if something can be done at comptime to generate int ranges
<very-mediocre>
comptime is a bad way to put it
<very-mediocre>
i mean a minimal-cost abstraction
<very-mediocre>
static when needed.
<skyfex>
I think LLVM optimizations can handle it in most cases
<very-mediocre>
in userland we can do it as generators right now, but there's surely quite an overhead
<very-mediocre>
and LLVM doesn't optimize that yet apparently
<MajorLag2>
seems like a lot of effort to avoid declaring a variable outside a while loop.
<very-mediocre>
I'm actually OK with while loops, I'm just hopelessly into playing the devil's advocate for everything
<very-mediocre>
In my own code I just don't use the continue expression thing for while loops and do i+=1 at the end of the loop
<MajorLag2>
fair enough. I too find value in spitballing these things sometimes.
<very-mediocre>
I'm aware I can be annoying so I often have to remind that I think zig is awesome, there's very little to criticize honestly
<MajorLag2>
I didn't think it was annoying, I just thought that once generators came up as a solution it was worth mentioning that all you were doing was trying to avoid declaring a variable.
<very-mediocre>
that's true, ultimately that's what ranges boil down to. :/
<very-mediocre>
still removes quite a bit of boilerplate if you have a lot of nested loops
<very-mediocre>
or else languages wouldn't bother having range literals
<unique_id>
very-mediocre: I don't want to see your loops if you never make use of early continues. What about early returns? Skip them too? In my early continue/return can simplify the rest of the code a lot
<unique_id>
wow. I meant in my opinion
<very-mediocre>
Of course I use early continues and returns
<unique_id>
you said you do i+=1 at the end of the loop
<unique_id>
so you'll have to place that before all continues
<very-mediocre>
true
<very-mediocre>
so far it's been OK
<unique_id>
OK
<very-mediocre>
i may change my tune when I do more advanced things with zig
tiehuis has quit [Quit: WeeChat 2.2]
<very-mediocre>
in many of those cases I'd be using `for`
<very-mediocre>
I find that most code that needs early continues is dealing with domain logic of some kind, often i'll be looping through an array
<very-mediocre>
rather than incrementing an int
hopppetosse has quit [Ping timeout: 264 seconds]
davr0s has joined #zig
hopppetosse has joined #zig
xtreak has quit [Remote host closed the connection]
<bheads_>
zig should be able to name while statments
<bheads_>
A: while(1) { B: while(1) { continue A; break A; }} << continue and break on the outer loop
<andrewrk>
dbandstra, it's planned so that _ = foo() is not allowed to ignore errors. I'll dig up the issue
<andrewrk>
nwsharp, we also have plans to have the compiler complain about call graph cycles, and then various not-fully-proven ideas about how to have recursion that is proven to be safe (you might need to allocate some heap memory)
<andrewrk>
bheads_, we have labeled while and for. the syntax is close to what you have: continue :A; break :A;
mtn has quit [Ping timeout: 252 seconds]
<bheads_>
yep got the syntax wrong, but there is no mention of that usage in the docs. So I was just guessing that this existed or that it would be a good feature to add
<andrewrk>
because the unwrapped optional expression is in scope
<andrewrk>
while (optional_node) |node| : (optional_node = node.next) {}
bheads__ has joined #zig
<andrewrk>
I'm totally open to changing this syntax, provided the new thing is somehow better, and all the problems that are currently solved stay solved
<bheads__>
I am personally fine with the colon syntax, just wondering if there was a syntax reason for it
<very-mediocre>
isn't it a bit of a half-measure, to add the 3rd param of a C-style for loop to while?
<very-mediocre>
I understand the reason for it, as unique_id mentioned before you'd have to repeat the incrementation if you had it in the loop body
<bheads__>
In truth you only need one kind of loop
bheads_ has quit [Ping timeout: 264 seconds]
<bheads__>
do {} << forever do (cond) {} << c while loop do (cond; incrementor) {} do (initializer, cond; inc) {}
<bheads__>
I had designed a language like this years ago
<bheads__>
though no for each kind of loop
<bheads__>
which I really like
<bheads__>
*** I mean really like the for each
<very-mediocre>
I think the ugly truth is the C for loop is ugly but we're used to it
xtreak has joined #zig
<bheads__>
The increament part is really important
<bheads__>
the init part is just a QOL
<very-mediocre>
true.
<bheads__>
the inc part prevents a lot of bugs that can happen when using gotos or just whiles
<andrewrk>
I think instead of documenting `this` I'm just going to propose to delete the feature
<very-mediocre>
crazy idea: while (var i: usize = 0 < 1 then i += 1)
<very-mediocre>
< n rather.
<very-mediocre>
but that looks rather monstrous upon reading it. lol
<andrewrk>
I'm not even going to consider for ranges until the fate of generators is decided
<bheads__>
andrewrk, I mean in the terms zig has them defined, loop over slices and optional types
<bheads__>
and what functionality will need to replace this?
<andrewrk>
I don't understand
<bheads__>
very-mediocre, I cant even read that X)
<andrewrk>
can you explain the question?
<bheads__>
didn't this give us comptime access to the scope?
<very-mediocre>
bheads__: I know, I always shoot from the hip. I'm in permanent brainstorm mode for everything. :/
<bheads__>
very-mediocre, never stop doing that! we need more of that in the world
<andrewrk>
I did a test run of removing the scope parameter from @setRuntimeSafety and it worked fine
<bheads__>
hummm I remember a proposal I had that would be solved using this, but I cant remember or find it.. I guess it was not that important any more :)
<very-mediocre>
somewhat offtopic: bheads__:`but I cant remember or find it` -> don't you wish every OS had a notepad in its system tray or equivalent, with tag-based indexing?
<bheads__>
lol, I wish I could just remember things better , and I am only in my 30s!
<very-mediocre>
I think I lost 3/4 of my possibly-good ideas because I failed to note them down / store them in a retrievable way
<very-mediocre>
lol.
<bheads__>
What I need is a computer that records all my conversations and indexes them
<very-mediocre>
get a job at the NSA then. :)
<bheads__>
lol, just need to be a cyborg
<andrewrk>
I just trust myself to be deterministic, and think of the same solutions when I consider the same problems
<andrewrk>
I know where my keys are because I think "where would I put my keys?" and they're always there!
<very-mediocre>
so essentially you have pure functions for everything you do
<andrewrk>
yes
<bheads__>
lol if only like was so simple
<bheads__>
but no I forgot the non-deterministic things
<bheads__>
like a random person you meet at a party
<bheads__>
then you meet them again
<bheads__>
or you have one odd bug, you fix and move on. Then a year later your looking at that code again
<bheads__>
I get a lot of code written by other companies that like to copy code (oracle....) which includes all of the same bugs
<very-mediocre>
that was quite a scattershot thing you just wrote, lol
<bheads__>
shotgun chatting
<very-mediocre>
that's good imho, even if it makes me look like a fool, I think fast iteration and failure is good
<very-mediocre>
you should exploit zero-cost failure
qazo has quit [Ping timeout: 252 seconds]
<very-mediocre>
tbh it's the easiest way to learn something
<bheads__>
??
<very-mediocre>
say something on the internet that might be wrong, and you can be sure someone will educate you shortly :)
<very-mediocre>
you don't lose anything except reputation
<very-mediocre>
so just be anonymous when you do it
<bheads__>
sure, but I hate most of the internet
<bheads__>
social media the most :)
<very-mediocre>
you're telling me, I don't have facebook
<MajorLag2>
re: `this`, isn't `this` necessary for getting the type of `self` in non-top level struct definitions?
<bheads__>
andrewrk proposes an @thisType
<bheads__>
to find the scope
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bheads__>
it does open up to use this as a name which is nice
<very-mediocre>
Feels like unnecessary usage of `inline` and `comptime` should be warnings, except zig intentionally has no warnings
<very-mediocre>
and I have to say I like not having warnings, so I'm conflicted.
<andrewrk>
in general, inline should not be used to guess how to optimize code
<andrewrk>
it should be used when creating a stack frame for the function call would be semantically incorrect
<andrewrk>
this is important in OS dev and embedded dev
<bheads__>
a possible idea would be to have a check and sanitize mode in the compiler that checks these things
<very-mediocre>
maybe it's in the scope of zig fmt?
<very-mediocre>
like lint + format
<andrewrk>
e.g. you can call inline functions before you set up the stack but not normal functions
<very-mediocre>
right... But what if as a programmer my intent was referential transparency of a function
<bheads__>
but your not really calling an inline function
<very-mediocre>
like in the range example I posted above, the idea was to express a macro-like usage
<andrewrk>
with current zig semantics, you want `comptime range()`
<very-mediocre>
ah, I see!
<andrewrk>
until that one issue is solved you would need to do this at the callsite
<very-mediocre>
instead of marking "try to be comptime," shouldn't everything be comptime if possible?
<bheads__>
and inline loops are for loop unrolling, which can be a really good performance booster (reducing cache misses)
<andrewrk>
very-mediocre, I'm going to explore that. the key question is if the function is: fn foo() { unreachable; }
<andrewrk>
then should every function call to foo be a compile error?
<andrewrk>
I think the answer is - only when we can prove that it's on the guaranteed-to-be-executed path
<andrewrk>
e.g. if you did pub fn main() void { unreachable; } this should be a compile error - we know for sure control flow will hit unreachable
<very-mediocre>
that makes sense
<very-mediocre>
couldn't it be that you'd have to mark the function as dynamic/runtime
<very-mediocre>
if you really wanted to call it?
<very-mediocre>
otherwise it'd be safer to have it be a compiler error
<andrewrk>
that's a good point, maybe the default can be the other way
tyler569 has quit [Ping timeout: 265 seconds]
<very-mediocre>
I thought the point of `unreachable` was safety
<andrewrk>
the other issue is if the function takes more than 1000 backwards branches at compile time to analyze
PCBOB has joined #zig
<andrewrk>
e.g. fn foo() void { var i: usize = 0; while (i < 1001) : (i += 1) {} }
<andrewrk>
if you call foo() somewhere we would get an error: analysis exceeded 1000 backwards branches
<very-mediocre>
right
<very-mediocre>
it's already the case for top-level consts though
<andrewrk>
yeah. I think there's a good chance the issue is resolved in favor of zig optimistically evaluating functions at comptime when all the args are comptime known
<bheads__>
except extern ?
<very-mediocre>
I mean if you introduced a way to mark functions to try to be comptime, that'd clash with implicit comptime stuff
<andrewrk>
bheads__, right of course
<very-mediocre>
either we'd have to explicitly mark those ones too, or go for the reverse paradigm of marking things dynamic on purpose
<very-mediocre>
like "this function does so many iterations, I'd prefer to do it at runtime"
<andrewrk>
we used to have that
<bheads__>
in your foo example, if you try to run it in comptime and it fails, then it should auto be runtime
<bheads__>
unless you call it explicitly
<andrewrk>
but wouldn't you want to know? maybe you were counting on it asserting some condition and now silently it went from 999 to 1001 and you don't realize it's no longer comptime
<bheads__>
then mark it as comptime
<bheads__>
if I call foo I dont want the compiler to fail just cause it could run it in comptime
hopppetosse has quit [Ping timeout: 240 seconds]
<andrewrk>
yeah. anyway. I think the various issues and tradeoffs of this issue are clear now
<andrewrk>
back to self-hosted compiler work
<bheads__>
lol mush mush!
<very-mediocre>
Do I dare venture into compilter internals? Alas, not today.
davr0s has joined #zig
tyler569 has joined #zig
return0e has quit []
xtreak has quit [Remote host closed the connection]
<very-mediocre>
one of the more exciting things about zig
<MajorLag2>
won't that bool implementation create 2 new random ints for each time it is run on a bool? Or is caching being relied on?
<andrewrk>
MajorLag2, it will create 2 new random ints per seed
<very-mediocre>
the seed is constant
<MajorLag2>
Yeah, ok, I see it now.
<andrewrk>
right, the random ints it creates are static constants
<andrewrk>
in release mode I'm guessing the entire hash functions will be inlined
<MajorLag2>
yeah, and only the first passed bool will cause a new function to be created.
<MajorLag2>
so it'll work out as long as the hashes don't need to be consistent across builds.
<very-mediocre>
why is that? a good seeded rng should be consistent
Bas_ has joined #zig
<MajorLag2>
because the order will matter
<very-mediocre>
oh right
<very-mediocre>
the seed is shared
<andrewrk>
I think it's deterministic
<andrewrk>
I'm passing in seed explicitly - if you pass the same seed, you get the same values
<very-mediocre>
yeah since separate functions are generated, it's deterministic after all, each generated function should have its own instance of rng, no?
<andrewrk>
correct
<MajorLag2>
yeah, I think you're right, because the state of the rng isn't shared
<andrewrk>
it's a waste - but a comptime waste, not a runtime waste
<andrewrk>
easy to cache
bheads_ has joined #zig
<very-mediocre>
If anonymous functions are added, comptime is really going to fly
bheads__ has quit [Ping timeout: 260 seconds]
<very-mediocre>
it wouldn't add new functionality per se but it'd be much more expressive
<very-mediocre>
maybe it's just me but I waste a lot of mental energy on where to define certain functions
<andrewrk>
when you say anonymous functions, are you describing syntactic sugar, or something semantic?
<very-mediocre>
I mean inline function definitions a-la JavaScript
<andrewrk>
because you can do: const F = struct { fn f()void{} }.f;
<very-mediocre>
that's interesting but a bit ugly
<andrewrk>
right, but that's why I'm asking if you're talking about syntactic sugar - make it prettier - or something that has to fundamentally change
<very-mediocre>
yes, it'd be syntactic sugar
<very-mediocre>
something like C++ closures and anon functions is technically syntactic sugar too
davr0s has joined #zig
<very-mediocre>
say you had a comptime macro-like function range(type:T, a:T, b:T) [@intCast(usize, b - a)]T like in my previous example, I'd like to add a 3rd param "step function"
<Bas_>
What I don't like about the C++ closures is that you now basically have two ways to create functions ^^
<very-mediocre>
obviously you can go and write out step functions and import them
<very-mediocre>
but it'd be really intuitive to just write them inline
xtreak has quit [Remote host closed the connection]
zolk3ri has quit [Quit: leaving]
<andrewrk>
I don't remember where that landed
<GitHub1>
[zig] winksaville opened pull request #1285: Add formatted printing of pointers (master...add-formatted-printing-of-pointers) https://git.io/fNB4E
<winksaville>
andrewrk: #1285 is a first stab and adding support for "{p}" for pointer printing. There is debug logging which I'll remove before merging, but I wanted to keep them until this was approved to make it easier to test/debug.
<andrewrk>
thanks winksaville - I'll have a look
xtreak has joined #zig
<winksaville>
andrewrk: Any thing else you want me to do to www.ziglang.org #18
<andrewrk>
nope, I'll try to get around to that later today, thanks
kristate has joined #zig
xtreak has quit [Remote host closed the connection]