<marler8997>
andrewrk, I had another idea to solve the start bootstrap problem
<marler8997>
if we had @tryImport, then std.zig could do something like: comptime { _ = if (@tryImport("start")) |s| s else @import("start.zig") }
<marler8997>
since std is always evaluated, it adds a "hook" into std that allows the "start" package to be overriden, and it's nice because it's implemented in the std library instead of being hardcoded in the compiler
rom1504 has joined #zig
<ifreund>
I don't mind having something hardcoded in the compiler if it means avoiding adding a new language feature (@tryImport())
<marler8997>
agree, this alone wouldn't justify @tryImport
<ifreund>
if @tryImport() was decided to be a good idea for other reasons, sounds like a reasonable way to implement that though
<andrewrk>
I'm guessing that will be one of the topics of the specs meeting tomorrow? :)
<marler8997>
@tryImport might be mentioned, maybe just briefly
bndbsh has quit [Quit: Connection closed for inactivity]
<marler8997>
is there a way or a trick to create a string constant, but not allow it's contents to be used at comptime?
<ifreund>
I kind hope there isn't :P
<marler8997>
I mean, you could just declare it as extern and link it in later, but I'm wondering if you could do it in pure zig without compiling it separately
<andrewrk>
marler8997, var x = "foo".*;
<marler8997>
not sure that's what I'm looking for, the use case here is my buildpkgs proposal is incomplete, a module needs a way of reporting it's "package path" to the build system, but a modules package path shouldn't affect it's compilation, so I'm wondering if there's a way to give it access to the path at runtime, but not allow it to read the contents at comptime
<ki9a>
andrewrk: you guys working on a native zig backend to partially replace llvm now?
<ifreund>
though it will only truly replace llvm for debug builds for the forseeable future
voldial has joined #zig
<ki9a>
that makes perfect sense. I don't think anyone really can replace llvm's optimizations in a near time
<andrewrk>
we have some promising results as far as compilation speed so far, but only time will tell if we can maintain it all the way through full language implementation
<ki9a>
I was actually looking at cranelift the other day for my own compiler
<ki9a>
but it's the same kind of idea as what you are doing
<andrewrk>
yeah. cranelift looks legit
<voldial>
How do I not link std? it's still in here, I assume I'm using it implicitly? echo "pub fn main() u8 { return @as(u8, 42); }" > return_42.zig && zig build-exe return_42.zig
<andrewrk>
voldial, you're only using what you depend on. probably you're noticing code for the default panic handler. you can override it
<andrewrk>
there is also (necessary) code that runs before main()
<voldial>
aah. undestood. I'll go watch the hellos tutorial again
<andrewrk>
are you passing a freestanding target to the compiler?
<voldial>
oops. nope to that too.
<marijnfs>
Nypsie: thats not bad, i'm sure someone will build a native one in zig at some point
<andrewrk>
voldial, that's probably the only issue then :)
<voldial>
andrewrk: TIL:)
<andrewrk>
marijnfs, it probably works fine to cimport the boltdb headers too
<andrewrk>
translate-c is pretty sophisticated these days
<xackus>
unless it's macros with ## like mingw uses to define integer literals
<andrewrk>
yeah but even those we have some pretty decent heuristics
<andrewrk>
if it's just integer literals, zig has you covered
<xackus>
mingw has a macro for long literals which adds 'l' to the end
<xackus>
they could just cast it but no
voldial has quit [Ping timeout: 240 seconds]
<andrewrk>
pretty sure we have test coverage for that
pretty_dumm_guy has joined #zig
<xackus>
if it's just a literal with a suffix it works, but the suffix is added by a macro
<marler8997>
copied from the proposal: ...The problem is there's no way to forward a field from from a nested type to the parent. Unlike functions that can forward calls to other functions, fields have no ability to do this....
<g-w1>
have a getter function 🤷
<g-w1>
i think some std stuff does this
<marler8997>
getter functions is one solution but comes with it's own problems
<g-w1>
agreed
<marler8997>
copied from proposal: naming conventions, the choice to return values or references, handling mutable vs const references to @This(), and requiring the caller to go through a function that can execute arbitrary code when all they want to do is access the field.
<v0idify>
for a problem, there's always a zig proposal for it :P
<marler8997>
yeah it kinda seems like that huh? :)
paulgrmn_ has quit [Ping timeout: 240 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
pjz has quit [Ping timeout: 252 seconds]
lemur has quit [Quit: Konversation terminated!]
pjz has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
marijnfs has quit [Quit: WeeChat 2.8]
<v0idify>
there's no scrollbar when <750px width view on the auto-generated docs and the css is being weird
<v0idify>
on firefox
DarkPlutonium has joined #zig
DarkUranium has quit [Ping timeout: 260 seconds]
<v0idify>
how do i check for an error set in a switch?
<v0idify>
like switch (err) { ErrorSet => {} }
<g-w1>
you can't, switch on the errors in the error set
<g-w1>
unless you are switching on a type, in that case it will work
<v0idify>
is there no way to check if the error is inside the set?
<g-w1>
i think with some @typeInfo metaprogramming you can
<g-w1>
i might be overlooking something tho
<v0idify>
yeah i'm sure it's possible with that but i find it weird it's not possible with the language itself