<fengb>
daurnimator: it's not just optionals, the switch won't allow regular inferred enums either
<daurnimator>
if so then yeah please make a new bug report (without the confounding factor of the optional enum) unless you can find another relevant issue
<fengb>
I think this one is missing implicit cast on return values. I had the same problem for if statements
<fengb>
Or rather, it tries to cast to sibling branches instead of the return values
<ntgg>
fengb: It is seemingly fine for if statements for me?
<fengb>
Hmm I must be confused
<fengb>
So probably a bug in switches
<ntgg>
wait nvm, it doesn't work it if's either, I was just doing it wrong
<Tetralux>
ntgg: The 'pub' keyword causes declarations to be available in other files. (They are visible within the same file regardless of pub or not.)
<Tetralux>
Oh - For some reason I didn't see someone already addressed that.
<Tetralux>
Never-the-mind. xD
<Tetralux>
dimenus: Don't use zig fmt ;P /s
<fengb>
You can add some comments to prevent wrapping
<Tetralux>
I don't think there's built-in options to do that.
<fengb>
zig fmt has no options and should have no options
<gonz_>
Depending on the construct you can just add a comma, etc., in a parameter list or the like to have it split it over several lines
<dimenus>
i just disabled it :D
<gonz_>
The plus side of that is that it's then consistent and not up to you to suddenly wrap only on the 5th argument, etc.
<gonz_>
Because then suddenly it's "your style"
<gonz_>
And everyone else hates your style
<gonz_>
(as we should)
<gonz_>
The only good style is everyones' style
<fengb>
To paraphrase, zig fmt is nobody's favorite and thus everyone's favorite
<gonz_>
Exactly
<Tetralux>
Personally I think that you shouldn't wrap lines in the actual file, just in the editor.
<gonz_>
Yuck
<fengb>
So semicolon for ages? :P
<Tetralux>
Just leave those lines as long as you need em. Maybe wrapping for things that make obvious sense, but not always.
<Tetralux>
Anything longer than n chars can be auto-wrapped by the editor.
<gonz_>
The way `zig fmt` does it is reasonable, though I would prefer if it just forced newlines on long enough lines personally
<gonz_>
Either that or just force no newlines at all
<gonz_>
Just pick one
<gonz_>
Leave people 0 choice
<gonz_>
Not even with notation in code
<Tetralux>
I think pragmatism is the best approach.
<Tetralux>
"What will people have least trouble with?"
<Tetralux>
Since the editors can wrap the code and set up the tabs and stuff to whatever they like, I'd rather have the text itself be as dumb as bricks and have the editor be smart.
<Tetralux>
zig fmt is one way to do that.. ish.
<Tetralux>
But it's just another cog in the machine to work around.
<Tetralux>
Which is why I don't tend to use that kind of tooling.
<gonz_>
There is nothing pragmatic about leaving people choice here
<gonz_>
The pragmatic thing would be cohesion
<Tetralux>
I like programming. And people forcing decisions on me makes me not like what you're offering. xD
<gonz_>
Choice doesn't promote cohesive and unified style
<gonz_>
Well, don't call it something it's not
<gonz_>
Don't invoke pragmatism
<gonz_>
It's inherently a weasel word that can mean whatever you want it to mean
<gonz_>
In this very instance it's actually the very opposite of what you're arguing for
<Tetralux>
I made clear what I meant. If you don't feel like calling it pragmatism - that's totally okay.
<gonz_>
"If you don't feel like calling it..." :D
<gonz_>
Yeah, ok
<fengb>
Be excellent to each other /andrewrk
<Tetralux>
I'm not that bothered how you feel about what you wanna call it xD - I just think that leaving things as free as possible tends to make for a better experience if you want to work without friction.
<Tetralux>
And it's totally okay to like the auto formatting tools.
<Tetralux>
fengb: +1
<gonz_>
Give me a shout when you find an editor that doesn't make long lines look like garbage
<gonz_>
Also show me an auto formatter that provides choice that actually has done good for the community
<Tetralux>
What would you consider a non-garbage looking way to display it?
<Tetralux>
(.. And I'd rather not use one that customize it. Being able to is just as bad as having one IMO.)
<Tetralux>
than customize it*
<gonz_>
How is it bad to have an auto formatter? Every community that has unified around one is much better off for it, IMO
<gonz_>
They don't have pointless conversations about style, etc.
<gonz_>
You don't have people coming into new projects suddenly writing code that looks drastically different, etc.
<Tetralux>
The point about suddenly writing code that's different is an non-issue. In projects without a formatter, you just use the style that's obvious from the rest of the code.
<Tetralux>
But I get why you'd think a formatter is better than otherwise if you want to avoid the conflict of "I cannot accept this commit. Wrong style."
<gonz_>
It's not even only for commits, to be honest. Even cross-projects it's better to have one style in an open source community.
<gonz_>
The abundance of choice in language features in C++ is proof that choice isn't a strictly positive thing.
<gonz_>
In a primarily closed source community where everyone builds their own private toolbox "personal style" might be preferrable
fengb has quit [Ping timeout: 260 seconds]
<gonz_>
But it's a needless complication on top of trying to figure out whether or not the library you use has a bug to have it also be written in some odd style that the creator thought was nice (and that he's so proud of)
<gonz_>
So if I could I'd force newlines when lines are of a certain length and build auto formatting into a publishing step for a package manager
fengb has joined #zig
<gonz_>
Because consistency is more important than peoples' egos
<Tetralux>
I think C++ is a bad example of how lots of features are good anyway.
<Tetralux>
The features they chose are.... questionable.
<Tetralux>
You want several, extremely powerful features.
<Tetralux>
Not loads of weird cruft built on weird cruft.
<gonz_>
Even if you look at the subsets that reasonable people use in f.e. game development C++'s amount of choice is a problem.
<gonz_>
Those are features that most people have agreed are good but you still end up in a position where they all just choose different subsets.
<gonz_>
Haskell has tons of great features but suffers from the same problem. The problem is choice, regardless of feature quality. Needless choice like formatting is even worse.
<Tetralux>
I'm not sure that "people agreeing they're good" means much there unfortunately.
<Tetralux>
There's so many things they could've done better.
<gonz_>
And not providing as much choice would've been better than choosing good features is my point.
<Tetralux>
At this point, the only things that's good about C is that you can build fast static code with it, on many archs.
<Tetralux>
I half agree with you.
<Tetralux>
I'd just say that they should have chosen better features to begin with.
<Tetralux>
.. That are very powerfu.
<Tetralux>
And then they wouldn't need as many anyway.
<gonz_>
I agree
<Tetralux>
Like *complete* CTFE, for instance ;)
<Tetralux>
By which I mean, you can run your entire program at compile time if you want to.
<Tetralux>
Like... your 200,000 line game.
<Tetralux>
.. Not that you'd probably want to do _that_ specifically.
<Tetralux>
xD
<Tetralux>
That would allow you to... for instance... enforce the MISRA standard on parts of your codebase.
<Tetralux>
Ensure that Entities that live in one location don't get used the wrong way...
<Tetralux>
etc.
samtebbs33 has joined #zig
<Tetralux>
..And write code like you're writing a normal program, but yet still run it at comptime.
halosghost has joined #zig
<ntgg>
is it possible to switch on two things at once?
<Tetralux>
I don't think so.
<Tetralux>
What's your usecase?
<ntgg>
I want to rotate a matrix based on an two enums representing the in/out direction
<ntgg>
I can just use if/else
<ntgg>
but a switch would be cleaner
fengb has quit [Remote host closed the connection]
fengb has joined #zig
THFKA4 has joined #zig
<emekankurumeh[m]>
wish zig had pattern matching
<halosghost>
k
<dimenus>
is it safe to take the address of a function returning a struct?
<dimenus>
or is that unintended?
darithorn has joined #zig
Akuli has joined #zig
<Tetralux>
The address of a fn that returns a struct?
<Tetralux>
That seems perfectly reasonable.
<Tetralux>
I'm not sure I quite get your usecase xP
fengb has quit [Ping timeout: 260 seconds]
Flaminator has joined #zig
very-mediocre has joined #zig
darithorn has quit [Quit: Leaving]
ntgg has quit [Ping timeout: 248 seconds]
<very-mediocre>
is there, or should there be, a convention for things that allocate heap memory vs things that don't? Also, "static" vs dynamic variations of things, e.g. I've got a ring buffer with comptime known capacity (if it's a power of 2, modulus is replaced at comptime with a bitmask)
<very-mediocre>
I mean a naming convention
<very-mediocre>
I find myself needing to write a dynamic capacity version of the ring buffer now, and I'm running out of names
<very-mediocre>
er bad example maybe, i guess that just makes it a queue
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
FireFox317 has joined #zig
<mikdusan>
not sure about convention but i've seen "fixed" used in naming quite a lot to indicate static sizing
<FireFox317>
Hmm, some recent commit broke the compilation of the zig compiler. I now get an error when running make install
<very-mediocre>
mikdusan: thanks, I'll just go with that. gets messy fast, and imho ruins C code
<very-mediocre>
probably not so bad in zig thanks to the other niceties
<mikdusan>
FireFox317: most recent commit d23798a296ddab023009dab860b6cb9361a62abd breaks building zig for me macOS
<FireFox317>
mikdusan: Yeah, i'm checking it too right now. It is indeed the last commit, now it builds fine
<FireFox317>
andrewrk ^^
<Tetralux>
Most recent commit breaks on my Linux machine too.
<mikdusan>
seems to not be an issue on CI builds
<andrewrk>
ok reverting now
<FireFox317>
Maybe its a small fix
<mikdusan>
ninja: error: '/opt/llvm-8.0.1/lib/-lLLVMSymbolize', needed by 'zig0', missing and no known rule to make it`
<andrewrk>
ah
<FireFox317>
Same for linux
<Tetralux>
Yeah - By "most recent" - I mean the one that changes the Findllvm file.
<mikdusan>
might be related to `Debug` build of zig
<mikdusan>
switched to `-DCMAKE_BUILD_TYPE=Release` and am able to build
<Tetralux>
I get "'xcore-max-threads' registered more than once" if I try to build release on linux...
<Tetralux>
I don't think that's related to this commit though.
<very-mediocre>
for whomever may find this interesting: a solution to the ringbuffer issue above is - whether the capacity will be static is known at comptime, so I can add a comptime flag that says it will be dynamic - in which case an ensureCapacity function will get codegen'd into the various functions
andersfr has joined #zig
<very-mediocre>
I love how comptime works. I'm not used to thinking this way.
<very-mediocre>
the only thing that remains is hypothetically whether to call it, say, AllocatingRingBuf, to distinguish from one that's always fixed backed by stack memory
<very-mediocre>
#ocd
andersfr has quit []
darithorn has joined #zig
<Tetralux>
Another option is to have an init fn for it that you supply a slice to.
<Tetralux>
(.. which could be stack memory.)
<Tetralux>
That seems the simplest :)
<very-mediocre>
true but that doesn't address whether to call ensureCapacity or not
<very-mediocre>
oh, what you said works for the second scenario (naming convention)
<Tetralux>
You can supply it an allocator for heap, or call .initFixed or w/e for stack.
<Tetralux>
If slice, slice.len is the capacity, if allocator, ensureCapacity.
<very-mediocre>
or just use the "comptime param determines whether it resizes dynamically" solution, and then make it false and accept a buffer here on the stack
<Tetralux>
I've not looked at what ensureCapacity does, but I assume it just ensures that there's at least a certain amount of space xD
<Tetralux>
I assume you'd be resizing dynamically if you tried to allocate something from the ring buffer that's bigger than the size of the bufer?
<Tetralux>
If so, I think I'd make it either panic or return OutOfMemory.
<Tetralux>
Maybe in debug panic, in release OOM.
<very-mediocre>
it's basically a queue so you put() and take() stuff, but I also sometimes want a dynamic queue with good cache locality (read: not a linked list), hence this discussion
<very-mediocre>
for the latter scenario, yes, it needs to grow
<Tetralux>
If it's a queue, it should auto-expand if it needs to... Could try a BucketArray of some kind.
<Tetralux>
(.. constant time append.)
<Tetralux>
It's not too clear to me why you _wouldn't_ want to it auto-expand.
<very-mediocre>
because i'm attempting deflate and it uses a lot of fixed-size buffers with queue characteristics
<Tetralux>
Maybe have .init take an optional allocator which it uses if the fixed-array is depleted.
<very-mediocre>
the solution discussed above is fine, i'll stick with that
kristoff_it has joined #zig
DutchGhost has joined #zig
<DutchGhost>
can we have `compile_error_if(condition: bool, msg: []const u8)` ? :3
<very-mediocre>
actually the comptime keyword is unnecessary, if the condition is comptime it should be implied
<very-mediocre>
yep!
kristoff_it has quit [Ping timeout: 245 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
very-mediocre1 is now known as very-mediocre
qazo has joined #zig
<DutchGhost>
noo it would be `if(...) { @compileError(....) }`. However then you need to write the if's each time and the @compileError each time
<very-mediocre>
make it a function and run it at comptime with the comptime keyword
qazo_ has joined #zig
<mikdusan>
that works but does add a stack frame in diagnostic output
<very-mediocre>
Could be wrong, I'm a bit burned out: define `fn compile_error_if(comptime condition: bool, msg: []const u8` then call it like `comptime compile_error_if(somethingDeterminedAtComptime, "Something bad happened at comptime!");`
<DutchGhost>
I wonder if I handle the *const T and *T Iterators in a good way?
avoidr has joined #zig
FireFox317 has quit [Ping timeout: 260 seconds]
ntgg has joined #zig
<hryx>
since files are just structs, is it possible to "instantiate a file"? I.e. `const r = @import("robot_type.zig"){.height = 20, .color = .Green};`
<andrewrk>
yes
<hryx>
that's pretty cool. would that be considered a good pattern? `@import("Allocator.zig")`
<hryx>
it could set an interesting precedent
<andrewrk>
I think we're slowly moving towards that being the pattern
<very-mediocre>
It's basically a statically analyzed version of node.js `require`
<andrewrk>
yes
<companion_cube>
there are some posts on D that emphasize local imports (as opposed to toplevel ones), since their imports are also scoped
<hryx>
it's also the same as require in lua
<ntgg>
Is there a way to test for a compile error?
<DutchGhost>
wait so how do you defined the `height` and `color` fields in the file? `const r = @import("robot_type.zig"){.height = 20, .color = .Green};`
<very-mediocre>
you can write them like members, no var or const
<andrewrk>
DutchGhost, yes, in zig files are structs
<DutchGhost>
man that's crazy
<DutchGhost>
but cool!
<very-mediocre>
any chance of making it C# or Javaish (I know, I know) where you're obligated to write a struct? Would be more explicit
<DutchGhost>
so wait, does this enable kinda like a `workspace` thing?
<andrewrk>
very-mediocre, probably not
<DutchGhost>
where you can have multiple `workspaces` as being different instantiatiens of a file?
<DutchGhost>
*instantiations
very-mediocre has quit [Read error: Connection reset by peer]
<andrewrk>
that's just structs
very-mediocre has joined #zig
<very-mediocre>
Oh, I see. I thought it could be a top-level anonymous struct expression to make it clear, just like struct{ (your code contents here) }
<DutchGhost>
Yeah, but then you could have a file declaring for example an allocator, and use that globally...and oh well, just hot swap it with another instance of it that puts in a different allocator
<companion_cube>
it'd be in every file then
<DutchGhost>
and suddenly your programm uses a different global allocator and its all good
<Tetralux>
*slowly backs away*
<DutchGhost>
why do you people come up with such cool things ohmy hahaha
<very-mediocre>
Lots and lots of precedent for neat programming language features in 2019. I don't envy andrewrk's position here.
gonzus has joined #zig
<andrewrk>
there's an infinite number of neat programming language features that zig won't ever have
<gonzus>
I was just watching the latest twitch video. Great new stuff in zig, congrats!
<companion_cube>
andrewrk: well it has dependent types and staged programming, that'd qualify for a lot of neat features :p
fengb has joined #zig
<DutchGhost>
staged programming?
<gonzus>
A humble request: would it be possible to avoid the music track? I personally find it very difficult to concentrate on what is being said.
<companion_cube>
DutchGhost: 2 stages of evaluation (comptime+runtime)
<DutchGhost>
ahhh yeahh
<gonzus>
Also, the video was in fact muted at some points, probably due to copyright protection?
<andrewrk>
gonzus, that's the first one I did music with, just an experiment. thanks for the feedback
<andrewrk>
damn I was worried that would happen
<andrewrk>
I really should upload somewhere other than google
<gonzus>
The music was cool. I just want to concentrate on what you are saying... :-)
<andrewrk>
these 3 features were pretty difficult to do together: result location semantics + inferred comptime + peer type resolution
Akuli has quit [Quit: Leaving]
<DutchGhost>
Zig.... It's a small hello world, but a giant leap for programmers?