ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Ping timeout: 240 seconds]
return0e has quit [Ping timeout: 263 seconds]
return0e has joined #zig
isd has joined #zig
KingOfThePirates has joined #zig
Taslem has joined #zig
davr0s has joined #zig
<itsMontoya>
andrewrk: It's a red-black tree which uses MMAP
<andrewrk>
memory mapped disk I/O makes it hard to handle I/O errors
<andrewrk>
because now writing to memory can fail, and in order to handle it you need a signal handler
<andrewrk>
which is basically the COMEFROM statement
<itsMontoya>
True
<itsMontoya>
That's currently the fastest implementation though
<itsMontoya>
It's what LMDB does as well
<itsMontoya>
Theoretically, errors are rare outside of grows
Taslem has quit [Ping timeout: 260 seconds]
<andrewrk>
it's a conundrum isn't it? makes me think that the OS API is deficient
<andrewrk>
there must be a way to have the speed without the lack of error handling
<itsMontoya>
I agree
<itsMontoya>
What write errors can actually occur though?
<itsMontoya>
If the space is already allocated
<itsMontoya>
Like, I know when you call write on a file descriptor. One error is out of space, if the file is extended and the OS cannot provide more space
<itsMontoya>
I'm not sure what other errors really happen. That's all I've encountered in the wild
<andrewrk>
there's also EIO, "A low-level I/O error occurred while modifying the inode."
<itsMontoya>
Fair enough
<itsMontoya>
It would be essentially a silent error
<andrewrk>
which would be useful to report with something like, "heya, user, I have some bad news: your hard drive appears to be failing"
<itsMontoya>
I guess an OS will have to be written in zig that doesn't follow POSIX
<itsMontoya>
:P
<itsMontoya>
Agreed though, if you had the error messaging. You could notify of error rather than silently failing (and therefore corrupting data)
<andrewrk>
EFBIG "An attempt was made to write a file that exceeds the implementa‐ tion-defined maximum file size or the process's file size limit, or to write at a position past the maximum allowed offset."
<itsMontoya>
Well that's a panic in go
<andrewrk>
you could make an argument that this a database configuration error, and the db has undefined behavior if this error occurs
<itsMontoya>
Because it's an out of bounds error on the slice
<itsMontoya>
But if you properly manage you tails, you are fine
<andrewrk>
I'll concede that it's a rather small error set
<andrewrk>
but it seems pretty important to me that you should return failure if your DB commit fails due to ENOSPC or EIO
Taslem has joined #zig
<itsMontoya>
I totally agree
<itsMontoya>
It would be nice to have
<itsMontoya>
For instance, with my DB. I could avoid merging the bad branch
<itsMontoya>
and save the data integrity of the existing data
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
KingOfThePirates has quit [Quit: Page closed]
<itsMontoya>
I'm out! I'll hop on IRC tomorrow
<itsMontoya>
Take care all
itsMontoya has quit [Quit: Lost terminal]
<jab>
I've built zig, but it fails when building its std
<hobomatic>
(i think i only changed the cmake install dir)
<hobomatic>
the install prefix passed to it
tiehuis has quit [Quit: WeeChat 2.1]
<hobomatic>
and not running all the tests
SimonNa has quit [Quit: Leaving]
hoppetosse has joined #zig
hellerve has joined #zig
<hellerve>
good morning (at least in germany it is)!
hellerve has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
davr0s has quit [Client Quit]
hellerve has joined #zig
return0e has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
return0e has joined #zig
return0e_ has quit [Ping timeout: 268 seconds]
return0e has quit [Ping timeout: 248 seconds]
<hellerve>
hey! i have trouble installing the dev build (specifically stage 3). the output tells me that `build` is an unknown command. funnily enough, it’s listed as an available command in the usage section. is that a known bug or did i do anything wrong?
Hejsil has joined #zig
<Hejsil>
hellerve, you can't build the self hosted compiler with the self hosted compiler yet :)
<hellerve>
ah, well, that explains it
<hellerve>
should there be a disclaimer or something?
<Hejsil>
There is this under stage 2: Note: Stage 2 compiler is not complete. Beta users of Zig should use the Stage 1 compiler for now.
<hellerve>
aha
<hellerve>
i wanted to hack on zig a bit and figured i should use the self-hosted compiler, but nevermind then! :)
<Hejsil>
Ye, if you want to play around with a working compiler, the stage 1 compiler in C++ is the way to go
<Hejsil>
But I'm sure andrewrk wouldn't mind if some love was put into the self hosted compiler
<hellerve>
haha, before taking that on i should probably get a working dev setup
return0e has joined #zig
<hellerve>
im trying to work out issue 792 right now; i’m sure i’ll bug y’all a bit with questions later.
<SimonNa>
and very much correct assumption how people write exception code. In the top-level main loop in my D program, I have catch (Throwable) { log to file, rethrow to crash }
<SimonNa>
even though it rarely fires, once in a blue moon it's helpful
steveno_ has joined #zig
<MajorLag2>
I think I will forever see OOM as the Ski Free monster now.
hellerve has joined #zig
<hellerve>
potentially stupid question incoming: i get an error i dont understand when hacking on zig. namely i get an error when running `build.zig` that `debug.dumpStackTrace()` expected 1 arguments & found 0. the error occurs in std/os/index, in unexpectErrorPosix, a function i havent touched
bw___ has joined #zig
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bw___ has joined #zig
bw___ has quit [Client Quit]
Hejsil has quit [Quit: Page closed]
noonien has joined #zig
<hellerve>
to clarify: i also looked at the code in question and how its being used, and it is indeed never passed an argument. this doesnt seem to be a problem in master, though, and i’m not sure why.
return0e has joined #zig
Hejsil has joined #zig
<Hejsil>
hellerve, It seems like a bug in the standard library. Zig has lazy top level declaration, so if a function isn't used, it isn't analysed.
<Hejsil>
I'm not quite sure though, as I can't reprocude this error
<Hejsil>
Is "unexpected_error_tracing" set to "true" in std/os/index.zig?
Hejsil has quit [Quit: Page closed]
hellerve has quit [Ping timeout: 260 seconds]
hellerve has joined #zig
<hellerve>
yes, that’s part of the wip branch that im looking at (by andrewrk, part of issue #792)
<andrewrk>
hellerve, can you give a link to a paste of more output?
<andrewrk>
hellerve, nevermind - it's a bug in the stdlib, I'll just push a fix
<GitHub63>
zig/master 0b7b319 Andrew Kelley: fix bitrotted code in unexpected error tracing
<andrewrk>
hellerve, ^
hellerve has quit [Ping timeout: 260 seconds]
hellerve has joined #zig
<hellerve>
oh wow, that was quick!
<hellerve>
thanks!
<andrewrk>
dumpCurrentStackTrace has an optional argument which is the first return address you want to start dumping at (since you usually don't want a few call frames leading up to dumping the trace)
<hellerve>
that makes sense
<hellerve>
alright, that fixed this error in particular. i still have to figure out how to actually make dirent work on os x, but at least i have a working setup now
meena has quit [Remote host closed the connection]
meena has joined #zig
<andrewrk>
hellerve, did you see my wip branch?
<hellerve>
yeah, thats what i was trying to get to run
<hellerve>
i rebased it and am working with it now
<andrewrk>
I was looking at apple's open source libc implementation
<andrewrk>
for inspiration
<hellerve>
ah, good call
<hellerve>
there are no tests for the syscalls/that syscall, correct?
<andrewrk>
there's one in that branch - std/os/test.zig
<andrewrk>
"makePath, put some files in it, deleteTree"
<andrewrk>
the call to os.deleteTree will use the os.Dir interface which will call that syscall
<hellerve>
ah, gotcha
<hellerve>
i dont really think ill be able to finish this quickly (having no experience with zig and all), but ill try my best; if anyone is faster than me or has more time to spare, no hard feelings
<hellerve>
ill comment on the issue again as well, so people know that i haven’t committed to taking this up
<andrewrk>
no worries. it's cool that you're contributing. don't be afraid to ask questions
<hellerve>
thanks!
Ichorio has joined #zig
<occivink>
hi, the talk mentioned concurrency (coroutines in particular) but I don't see anything in the docs (even in master), is it just that it's not documented yet?
<andrewrk>
occivink, correct. It's brand new and I haven't finished docs yet
<andrewrk>
I'm working on making error return traces work for coroutines (#821) then I'm going to finish up the wip-async-tcp-server branch which uses coroutines, and then try to multiplex coroutines onto a kernel thread pool, then write up docs, and a blog post explaining my findings
<hellerve>
bitCast is for casting values (e.g. ints, as opposed to pointers), right?
<andrewrk>
correct
<andrewrk>
mainly for something like f32 to u32
<andrewrk>
or i32 to u32
<hellerve>
okay, thanks!
<hellerve>
(context: needed it for __getdirentries->errnoWrap)
<andrewrk>
hellerve, if you're trying to debug code, I've found that lldb works pretty well on macos
<hellerve>
thats a good pointer, thanks
<hellerve>
i usually use it for my work on carp as well
<andrewrk>
cool
<hellerve>
i suppose the "address maps to more than one section" warning is known?
<hellerve>
i seem to get it for all programs i inspect under lldb
<andrewrk>
I've seen that but I don't know why it happens
<hellerve>
okay; ill ignore it for now, then
<hellerve>
thanks for your help! im going offline for a while and will work on this :)
<andrewrk>
cheers
hellerve has quit [Ping timeout: 260 seconds]
steveno_ has quit [Remote host closed the connection]
steveno_ has joined #zig
bw___ has joined #zig
curtisf has joined #zig
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bw___ has joined #zig
bw___ has quit [Client Quit]
bw___ has joined #zig
curtisf has quit [Ping timeout: 260 seconds]
itsMontoya has joined #zig
<itsMontoya>
Hey all
<itsMontoya>
make[2]: *** No rule to make target '/usr/lib/libclangFrontend.a', needed by 'zig'. Stop.
<itsMontoya>
andrewrk: Is this another lib I need to download?
<jab>
it's like C, which I love. all the new replacements like Rust and Go take widely different approached so not to become C, but Zig is very much in C's spirit
<itsMontoya>
Me too, I'm itching to get some projects going on it
<itsMontoya>
Well my issue with Rust is it's OVERLY complicated for all these "nicities"
<andrewrk>
itsMontoya, if the archlinux packages aren't working for you then I recommend building from source
<andrewrk>
rust is a really impressive project. I think there are pros and cons choosing zig or rust
<itsMontoya>
andrewrk: Fair enough
<jab>
itsMontoya: true, it has its purpose though. Go is C with a GC, Rust is C with no GC and no leaks possible, Zig seems to take the C but better approach
<jab>
and even hits some marks Go and Rust don't, like handling bad_allocs :P
<jab>
andrewrk: agreed
<itsMontoya>
I think your assessment of Go is completely correct
<itsMontoya>
I feel they maintained that C simplicity mantra, which really resonates with me
<jab>
interface{} is void*
<itsMontoya>
Or unsafe.Pointer
<andrewrk>
one of my goals with zig is that you can write truly reusable code
<itsMontoya>
andrewrk: Like modular?
<andrewrk>
you can use non-garbage collected libraries from garbage collected languages, but not vice versa
<itsMontoya>
In general, I try to break up everything into modules to ensure code re-use
<itsMontoya>
LLVM make install is at 9%
<andrewrk>
and then if you want all languages to be able to use your library then you have to be able to export a C API
<itsMontoya>
Go threadrippers! Do my bidding! (compilation..)
return0e has quit [Ping timeout: 256 seconds]
<jab>
I have a hard time thinking about code reuse on a high-level. Only for the most generic stuff any functionality does not live in isolation and carries assumptions around the environment it grew in.
<jab>
Basically for code re-use to happen a way to do something had to be perfect for all use-cases that need it, which is impossible
<andrewrk>
jab, agreed. but practically speaking, you would not write, say, ffmpeg in Python
<andrewrk>
instead it's in C and Python code that wants to support lots of media formats will use FFI to utilize it
<andrewrk>
on the other hand, writing ffmpeg in zig would be a safe bet, because you can have a C ABI
<jab>
gotcha
<jab>
yeah, that makes sense
<jab>
i usually turn to C when I want to write something that everything can use
<andrewrk>
this explains how zig stdlib print function works
<itsMontoya>
"In Zig, types are first-class citizens." <--- :thumbsup:
<MajorLag2>
That's kind of a feature of Go in my opinion. It has made their community open to rewriting things natively instead of using libraries, which is great if I need to, say, figure out how the kernel interface for FUSE works, because there is no documentation other than the libfuse source.
bw___ has quit [Client Quit]
<itsMontoya>
MajorLag2: "Feature"
MajorLag2 is now known as MajorLag
<itsMontoya>
One could argue happy byproduct
<itsMontoya>
But I disagree with feature
<MajorLag>
It's a feature to me, the guy reading their source and not writing Go code.
<andrewrk>
that's something go and zig have in common: producing static binaries
<MajorLag>
also great.
<andrewrk>
hello world in rust links against libc
<jab>
fat binaries are win
<MajorLag>
I remember when a fat binary was one that included code for multiple architectures.
<jab>
the fatter the better
<MajorLag>
Because shared libraries hadn't become a fad yet
<andrewrk>
a comptime_int implicitly casts to any integer type, and you'll get a compile error if it does not fit
<jab>
urm u32 to '+', narrowing the range
<jab>
gotcha
<jab>
that's cool
<itsMontoya>
I like this comptime shit
<itsMontoya>
This is really neat
<andrewrk>
jab, yes you would need an explicit cast to convert from u32 to u8. When you do this, you are asserting that the value is in range of the u8
<andrewrk>
so you can get a runtime panic in debug mode, or undefined behavior in release-fast mode if your integer is too big
<GitHub142>
zig/master 6cb99fd Andrew Kelley: fix crash when compile error in analyzing @panic call
<andrewrk>
jab, ^ fixed
<andrewrk>
std.debug.panic("{}", err) // if you want a format string
<jab>
panic is only good for []u8s/
<jab>
?
<andrewrk>
@panic is a low level intrinsic
<andrewrk>
it has to work across .o boundaries
<jab>
ahh
bw___ has quit [Client Quit]
<jab>
I'm always warry of taking addresses of function returns in non-GC languages: const stdout = &(io.FileOutStream.init(&(io.getStdOut() catch unreachable)).stream);
<andrewrk>
I wish jfo would not have put that code there
<jab>
How does this not create a dangling pointer if init returns something on the stack and I'm taking a reference to it
<jab>
Hahaha
<andrewrk>
it works exactly how you would expect: address of function returns is taking the address of a temporary stack variable
<GitHub176>
zig/master 5b00dee Andrew Kelley: std.math.cast handles signed integers
<jab>
so taking the address is unecessary in this case?
<andrewrk>
@panic calls the panic handler, which defaults to calling std.debug.panic
<andrewrk>
but you can override the panic handler by exposing pub fn panic in your root source file just like you do with pub fn main
<andrewrk>
I recommend using std.debug.warn to write to the console, unless you're making a program where you're actually trying to write some kind of formatted data to stdout
<Hejsil>
Oooh ye, that reminds me. Is stderr.print or debug.warn the best way to report errors?
<Hejsil>
To users of a terminal application
<Hejsil>
I guess debug.warn is better. It's not like I can recover from not being able to give users errors anyways
<andrewrk>
that's the idea
<andrewrk>
sometimes you would want to know about EPIPE but for kind of like error messages and things std.debug.warn is fine
<andrewrk>
if you were implementing git diff, you would be more careful about stdout - you'd probably want to exit 1 if you don't fully finish writing the diffg
<jab>
are there any facilities to help prevent duplicated error cases?
<jab>
defining an error that already exists except named slightly different
<andrewrk>
if you switched on such an error, and then enumerated all the cases, it would be pretty obvious
<andrewrk>
and you get a compile error for omitting a case
<jab>
ahh, yeah
<jab>
currently no default allocator?
<jab>
so malloc/free don't exist in some form in zig?
<jab>
and why are some enum constants inconsistent with naming? :P
<jab>
AtomicOrder.Release vs ObjectFormat.elf
<andrewrk>
the lower case ones are synchronized with LLVM's names
<andrewrk>
idk, a case could be made to do it either way
<andrewrk>
Hejsil, or if you were implementing a terminal gui, you'd probably want to know if writing control characters failed
<MajorLag>
@jab, there are some simple allocators shipped in std. DirectAllocator works for general cases.
<andrewrk>
if you're linking against C for other reasons, probably best to use std.heap.c_allocator
<Hejsil>
Naah, the randomizer right now is just: 1. pass arguments to program. 2. let program do it's thing the finish, reporting errors if any happend
<andrewrk>
Hejsil, yeah, for your case I think std.debug.warn is fine
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Hejsil>
But a terminal gui is a good usecase for stderr.print. Was trying to think of one myself
bw___ has joined #zig
<andrewrk>
if people are going to make fun of the zig community for anything, I want it to be that we sometimes sit around thinking about potential bugs that our software have, and then fix them anyway even though we haven't run into them yet
<Hejsil>
Lol, yes
bw___ has quit [Client Quit]
bw___ has joined #zig
bw___ has quit [Client Quit]
<andrewrk>
MajorLag, I've been off and on trying to get a build of clang, llvm, lld that uses musl instead glibc, and it's been really tricky
<andrewrk>
if I got that working, we could at least provide a single static linux zig binary
<itsMontoya>
andrewrk: So I installed llvm from source as per the instructions
<itsMontoya>
and when I look in ~/local/lib
<itsMontoya>
I don't see libclangFrontend.a
<MajorLag>
yeah, I got as far as getting llvm built I think. But I was also trying use libc++ from llvm instead of recompiling libstdc++ with musl, which I imagine presents its own difficulties.
bw___ has joined #zig
<Hejsil>
Building software from source is an NP complete problem. The only way to solve it is brute force
<andrewrk>
-- Found CLANG: /usr/lib/libclangFrontend.so;/usr/lib/libclangDriver.so;/usr/lib/libclangSerialization.so;/usr/lib/libclangSema.so;/usr/lib/libclangAnalysis.so;/usr/lib/libclangAST.so;/usr/lib/libclangParse.so;/usr/lib/libclangSema.so;/usr/lib/libclangBasic.so;/usr/lib/libclangEdit.so;/usr/lib/libclangLex.so
<andrewrk>
that's not what you just built
<itsMontoya>
Do I need to take a flag out?
<itsMontoya>
I posted my command
<itsMontoya>
at the top
<itsMontoya>
Maybe install prefix is conflicting?
<andrewrk>
I don't think it's that
<andrewrk>
unfortunately we don't have a way to tell cmake to prefer looking at CMAKE_PREFIX_PATH first
<andrewrk>
can you just remove the conflicting packages?
<itsMontoya>
Then do cmake again?
<andrewrk>
yes and make sure the output is correct
<andrewrk>
I think tiehuis uses archlinux. tiehuis did you have to do anything weird to build from source?
<MajorLag>
yeah, I had the same concerns jab. In general, I just initialize it to undefined, then set each variable I actually want individually afterwards. I zero it with a simple `for(([]u8)(struct))|*b|{*b = 0;};` it hasn't been as big a deal as I thought it would.
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
I don't think you want a const undefined pointer
<MajorLag>
var event: sdl.SDL_Event = undefined;
<MajorLag>
while (sdl.SDL_PollEvent(&event) != 0) {
<andrewrk>
yeah this will work fine
<jab>
ahh gotcha
<jab>
yep
<jab>
MajorLag: that's just memset
<jab>
why not use @memset?
<MajorLag>
yes, yes it is
<MajorLag>
well, because I ran into a bug with memset early on, and documentation says that for construct would compile to memset anyways.
<jab>
i see
<jab>
also, trying to wrap my head around the declarations. that for loop has a |*b| which captures the array iteration, but i would expect it to be &b
<MajorLag>
the documentation recommends the for construct because @memset is a low level intrinsic with no saftey.
<hobomatic>
there's also mem.set() that does that for you
<MajorLag>
I'm honestly not sure of the syntax reasoning there.
<hobomatic>
oh wait thats for slices
<jab>
and would |b| capture by value?
<MajorLag>
yes, if my understanding is correct.
<jab>
does the for loop dictate the type you can iterate or does the capture?
<jab>
if the for loop was iterating over an array of pointers how do you capture by value?
<jab>
andrewrk: nope, will look
<Hejsil>
Geeh. Just compiled Zig for a laptop and a debug version of Zig work fine, but release gives me: "CommandLine Error: Option 'color' registred more than once!"
<andrewrk>
Hejsil, that's strange, I have never seen that before until today where itsMontoya also ran into it.
<MajorLag>
jab, I'd probably take `|b|` and dereference it in the loop.
<andrewrk>
Hejsil, what distro are you on again?
<Hejsil>
Arch
<andrewrk>
same as itsMontoya
<Hejsil>
But on my desktop it works fine
<Hejsil>
This is some weird stuff
<andrewrk>
it appears to have something to do with mismatch of libraries. e.g. system clang + compiled from source llvm
<andrewrk>
I would double check your cmake output
<Hejsil>
I did not build clang and llvm from source
<Hejsil>
On both machines
<KingOfThePirates>
what's the recommended way to install vim for a noobie?
<Hejsil>
Oooh, maybe the wrong compiler is used for compiling Zig on the laptop
<andrewrk>
KingOfThePirates, the #vim irc channel is quite friendly
<jab>
&b makes more sense to me, but that may just be me. matches c++ syntax too with captures, and also creates the &b / *b duality, where *b / *b seems odd
<KingOfThePirates>
perfect, thanks
<MajorLag>
jab, yeah, I'm not sure of the reasoning behind how it works now, but it make more sense after the pointer reform?
<andrewrk>
yeah let's talk about capturing by reference in the pointer reform issue
<Hejsil>
It should be |x.&|. Just to keep the inconsistency :)
<MajorLag>
seems to me the construct would be something like `for(array) |*x| { x.& = 0; };`
<jab>
where is this discussion?
<Hejsil>
Shouldn't it be |&x|? * was for types
<jab>
MajorLag: that makes less sense, but i don't have context on pointer reform
<MajorLag>
jab, unfortunately to get the many great things that come with pointer reform we sacrificed the dereference operator a bit.
<MajorLag>
I think what I wrote should parse as "for every value in the array, give me a pointer to that value called x."... but that still seems a little off. Can't put my finger on it.
<jab>
hmm
<jab>
i see
<MajorLag>
*shrug*, all I can say is that it hasn't been a problem in practice regardless.
<jab>
derefencing with x.& is a lot of overhead
<jab>
2 special characters
<andrewrk>
jab, one of the important tradeoffs to understand about zig is that we're very willing to type more characters when writing code, in exchange for having lots of handy guarantees when reading code
<MajorLag>
the alternatives were worse. things like enforced parans around dereferences: (*var)
<jab>
so type delcaration: *u8, address of: &x, dereference: x.&
<MajorLag>
yeah, that's the gist of it. the block pointers are the real treat.
<andrewrk>
the really important thing is that *T is a pointer to exactly one T
<jab>
and multiple T's?
<MajorLag>
[*]T
<MajorLag>
if length is unknown at compile time.
<jab>
[*5]T if it is?
<andrewrk>
usually for multiple Ts you know how many there are at runtime, in which case use a slice: []T
<jab>
slice of pointers would be []*T?
<MajorLag>
yep
<andrewrk>
pointer to an array is *[N]T
<andrewrk>
[*x]attrs T, where x is any expresesion, is a syntax error
<jab>
[*]T is analagous to a C pointer then
<andrewrk>
yes
<MajorLag>
actually [*]null T is probably what you want.
<jab>
personally, i like all this... except for x.& :D
<jab>
why?
<jab>
you'd probably want it, but C arrays are not null terminated
<andrewrk>
here's another cool benefit: string literals would become `[N]null u8`. And then we can allow implicitly casting `[N]null T` to `[*]null const T`. So we no longer need C string literals - normal zig string literals will implicitly cast to where a c string is expected
<MajorLag>
true, they aren't necessarily, but a lot of apis use null terminated arrays. linux syscalls for instance.
<jab>
yeah
<jab>
andrewrk: i like that
<andrewrk>
having the type system know more facts lets us do more safe implicit casts
<jab>
how about instead of x.& it's x->, same ol' syntax and uses two special characters :P
<MajorLag>
I kinda don't like the non-C literal being null terminated, but I can't come up with a good argument why.
<jab>
almost looks like something is being carried out too
<jab>
var b: &u8 = a->;
<MajorLag>
anyways, I gotta duck out for a few hours.
<jab>
would become confusing when you see: a->.func()
<andrewrk>
MajorLag, there's a benefit besides C compatibility - you can avoid allocation overhead if you call posix APIs directly with string literals
<andrewrk>
I mean if you consider the linux syscall interface distinct from C compatibility
<jab>
but -> could be dual purpose
<MajorLag>
That is true... I could come around to it. It's that nagging extra byte...
<jab>
a->func() works like a.func(), a-> works like a.&
<jab>
erm, first case works like a.&.func()
<jab>
so for calling a function on a pointer struct you would have to do: a.&.func()?
<jab>
that's a very common operation to be so ugly
<andrewrk>
but using [ ] operators on `[*][N] T` is derefing the pointer, not the array
<andrewrk>
oh interesting - comptime slicing would give an array?
<andrewrk>
that's a really good question
<Hejsil>
Ye, pointer to array
<andrewrk>
I think there's still a distinction between a comptime array and a comptime slice
<andrewrk>
a slice is a reference
<andrewrk>
you can take the address of an element of a slice at comptime and it will equal at runtime the address of the original array that was sliced
<andrewrk>
even though the address is not known until linking
<Hejsil>
Wait? Im confused
<Hejsil>
I suggest slicing with constants returns a pointer to a fixed size array. Aka a refences as well :)
<andrewrk>
ahhh right of course
<andrewrk>
Hejsil, I think this is related to this question: what happens when you make an error union with an empty error set:
<andrewrk>
error{}!i32
<andrewrk>
at first I thought that this should just give you a i32
<andrewrk>
the problem I ran into was that calling code would use try, catch, if, on the value and it wouldn't work since it wasn't an error union
<Hejsil>
Ye, generics becomes a pain
<Hejsil>
But how is this related? :)
<Hejsil>
Are you refering to passing
<Hejsil>
*[2]u8 to []u8?
<Hejsil>
I would say that should be an implicit cast
<andrewrk>
I agree that should implicitly cast
<andrewrk>
but imagine generic code that slices, and then expects the type id of the result to be a slice
<andrewrk>
it might still be the correct thing to do
<andrewrk>
I'm thinking about it
<Hejsil>
Hmmm
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Hejsil>
Ok, two things!
<Hejsil>
1. generics have to handle *[2]u8 no matter what, so maybe pointer reformed is the problem itself
<Hejsil>
2. Have (*[2]u8)(slice) do the same as what I proposed with const slicing
<andrewrk>
and (2) would work as an implicit cast right?
<Hejsil>
Well, when you say s.x in generic code, then that's an interface requrement :)
<Hejsil>
Now all types that s can be must contain the field x :)
<Hejsil>
And then you go comptime assert(@typeOf(s.x) == i32) for the type
<Hejsil>
No need for complicated type systems when you have comptime! :)
bw___ has joined #zig
bw___ has quit [Client Quit]
<jab>
yeah, i really like comptime
<Hejsil>
andrewrk, I'll open a new issue for casting slices to array pointers as it is not directly related to Pointer Reformed. Pointer Reformed does however make indexing array pointers easier
<andrewrk>
Hejsil, sounds good
<Hejsil>
Oooh. Array pointer to slice implicit conversion already works lol
<andrewrk>
I think only if it's const
<Hejsil>
Correct
<jab>
i feel like there's still a lot to go for zig
<jab>
would writing a lib be less benificial than contributing to zig itself?
<jab>
(looking at milestones and issues)
<Hejsil>
Well, the more Zig's design is tested on real software before 1.0.0 the better
<jab>
true
<Hejsil>
Because I can imagine, the language will lock down a lot more when 1.0.0 happend
<Hejsil>
So better get those changes in now, that later
<jab>
are there any game libraries already in development?