<leeward>
At least, 1 error I don't know how to fix: compiling lib/std/std.zig leads to multiple _starts because it involves compiling start.zig.
nephele has quit [Ping timeout: 248 seconds]
nephele has joined #zig
muffindrake has quit [Ping timeout: 245 seconds]
muffindrake has joined #zig
_whitelogger has joined #zig
dingenskirchen has quit [Ping timeout: 245 seconds]
ur5us_ has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
dingenskirchen has joined #zig
dingenskirchen has quit [Remote host closed the connection]
mattmurr has quit [Quit: WeeChat 2.3]
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
dddddd has quit [Ping timeout: 268 seconds]
lygaret has joined #zig
darithorn has quit [Quit: Leaving]
lygaret has quit [Quit: Leaving.]
return0e has joined #zig
<bgiannan>
So i'd like to use std.sort but my lessThan function needs to compare things to a third party value (i'd like to sort points by distance to another point)
<bgiannan>
don're really know how to do that without closures
<mikdusan>
bgiannan: i have an ugly hack idea. create a wrapper struct that is "item" w/ 2 fields: { context, real_item } and now lessThan fn has access to context and lhs/rhs real_items
<mikdusan>
did I mention it was ugly? :)
<bgiannan>
right but you would sort a list of that wrapper struct and not the original list
<mikdusan>
yeah and it's kinda wasteful with (presumably) redundant context in each
<bgiannan>
the sort function itself should have a `context` parameter
<mikdusan>
hmm looking back on my comment: you're probably right, due to lessThan fn as param, probably need `comptime CT: type` as you correctly showed
<mikdusan>
we need an augment to comptime params. have compiler evaluate a constraint fn which returns an anonymous struct whos fields can be used in the rest of the fn param signatures.
muffindrake has quit [Quit: muffindrake]
jicksaw has quit [Ping timeout: 250 seconds]
jicksaw has joined #zig
muffindrake has joined #zig
lunamn has quit [Quit: leaving]
wootehfoot has joined #zig
marmotini_ has joined #zig
dimenus has quit [Ping timeout: 260 seconds]
marmotini_ has quit [Remote host closed the connection]
dingenskirchen has joined #zig
protty has joined #zig
<protty>
leeward: try using `zig test your_root.zig -femit-docs -fno-emit-bin --output-dir /path/for/docs/`
<andrewrk>
zig doesn't have address sanitization yet
<andrewrk>
I thought you were talking about -fsanitize=undef at first
<pixelherodev>
but shouldn't it be possible to detect that the value returned is of type pointer and the object pointed to is within the function even if it's not an explicit `return &obj`?
<andrewrk>
that's a good point. it would require introducing a rule into the language such as, "returning a pointer from a function asserts the pointer is dereferenceable" but that's probably a reasonable thing to do
lunamn has joined #zig
return0__ has quit [Remote host closed the connection]
<andrewrk>
the use-after-free issue tackles more complex situations, such as a pointer to a stack variable escaping via a struct field write
<pixelherodev>
Right, but I figure *basic* safety doesn't need to be withheld for the sake of not-yet-present complex safety mechanisms
<andrewrk>
agreed
return0e has joined #zig
<discip>
I don't know how compilers work, but isn't fsanitize part of LLVM, which Zig uses to compile?
<andrewrk>
there are more things to consider besides whether something could be technically hacked together or not
<discip>
Ah, so it's not as simple as passing a compilation flag
benjif_ is now known as benjif
<andrewrk>
there are language semantics to consider, a runtime library that has to be able to be cross compiled from source (or ported to zig), and llvm limitations to overcome (address sanitizer being incompatible with other things)
<andrewrk>
and then also just an audit of whether the design makes sense in the context of zig. there may be a better way to implement such safety, given the semantics of zig
<andrewrk>
it's a project that is worth exploring, but certainly nontrivial
<pixelherodev>
Given that files are imported as structures, is it possible to have *fields* in a file and an init() function, thereby avoiding an unnecessary inner structure?
<pixelherodev>
e.g. an allocator with an init function that returns a value of the type of the structure just imported?
<pixelherodev>
Oh yeah, I've looked at that issue before :P
<andrewrk>
as Jimmi notes, to close the issue, it's just Tests, std refactor, stage2 parser update
<pixelherodev>
Right right
<pixelherodev>
What's the "index.zig" convention it says not to use?
<andrewrk>
I think that was before your time
<pixelherodev>
Ah
<andrewrk>
instead of, e.g. std/os.zig and std/os/*, we had e.g. std/os/index.zig and std/os/*
<pixelherodev>
Ah
<pixelherodev>
I can see why that would be annoying
<andrewrk>
the only edge cases is std.zig is inside std/
protty has joined #zig
<pixelherodev>
Packages in general rather
discip has quit [Remote host closed the connection]
<pixelherodev>
On my Indomitable game for instance, it exposes the main folder as a package which is imported by the platform-specific frontends (which were the Root Source Files)
<pixelherodev>
So I had a file `indomitable.zig` being used in the same manner as std.zig :)
<pixelherodev>
I take it that private functions can then also be used in the standard `obj.fn()` manner?
<leeward>
Is `var stderr = std.io.getStdErr().outStream().stream` really the way to get stderr as a stream?
<leeward>
Also, should that coerce to `std.io.OutStream(anyerror)`?
<pixelherodev>
I think so
<pixelherodev>
To both of those
<pixelherodev>
Because getStdErr() gives you an std.io.File
<pixelherodev>
.fs.File*
<pixelherodev>
file.outStream() gives you a std.io.fs.File.OutStream
<pixelherodev>
Which has a field stream of type std.io.OutStream
<pixelherodev>
IIRC there's an issue to make getStdErr return the stream
casaca has quit [Ping timeout: 260 seconds]
<pixelherodev>
s/issue/proposal
casaca has joined #zig
<leeward>
That would certainly make users' lives easier.
<leeward>
Hmm, it seems like it's not coercing. @ptrCast here we come.
benjif has quit [Read error: Connection reset by peer]
benjif has joined #zig
<pixelherodev>
Wait really?
darithorn has quit [Remote host closed the connection]
<pixelherodev>
I don't think ptrCast is the correct answer there
return0e_ has joined #zig
<pixelherodev>
Ah
<pixelherodev>
The value returned by outStream() is an std.fs.File.OutStream
<pixelherodev>
its field stream is a value of type io.OutStream(std.fs.File.Error)
<pixelherodev>
leeward, why do you need to coerce it?
<leeward>
Trying to use LoggingAllocator
<andrewrk>
generic error sets & interfaces is not really solved right now, it's pretty awkward
<andrewrk>
I'm wondering if OutStream/InStream should use `anyerror` for their error sets, and rely on the API user to do an @errSetCast
<pixelherodev>
I can see advantages and disadvantages to that
return0e_ has quit [Ping timeout: 268 seconds]
<leeward>
Would it compile if the user just didn't cast the error set and had their functions return !void ?
<leeward>
Programmers will lazy.
<pixelherodev>
I'd argue that a good solution to generic errors is better in the long term
<pixelherodev>
For exactly those reasons
<pixelherodev>
Actually
<pixelherodev>
leeward, I don't think so
<pixelherodev>
That would be an inferred error set
<pixelherodev>
Not anyerror
<pixelherodev>
But I'd very much expect them to then just change it to anyerror!void
<pixelherodev>
It cheapens the value of error sets if a major library - let alone the *standard library* - explicitly makes it possible to misuse error sets in such a way
<andrewrk>
ideally, a language interface feature would solve error sets to be handled the way const is handled; coercion works in one direction
<pixelherodev>
Hmm
<pixelherodev>
Error set merging is already supported by the compiler, no?
<pixelherodev>
Not with a builtin AFAIK, but given that inferred error sets exist, I assume it can merge all possible error sets?
<pixelherodev>
If that's the case, I propose an @merge builtin
<pixelherodev>
If either provided error set is anyerror, it returns anyerror
<pixelherodev>
Problem is how that would work here...
<andrewrk>
pixelherodev, the || operator merges error sets
<pixelherodev>
Oh right!
<pixelherodev>
Hmm
<companion_cube>
could you have `_!foo` to have a unnamed, but inferred, error set?
<pixelherodev>
?
<pixelherodev>
`fn foo() !type` is already possible
<companion_cube>
ah yes, duh
<pixelherodev>
In what other situation would that make sense?
<companion_cube>
the difficulty with effects is when it's mixed with other abstractions, though, like high-order functions (closures) or templates :/
<pixelherodev>
Exactly
<companion_cube>
so probably you have to be able to name the effect but still have it inferred…
<pixelherodev>
Nah, that doesn't really help either
<pixelherodev>
If that was the case, just avoid having it inferred
<pixelherodev>
The fundamental problem here is that set is *generic*
<pixelherodev>
It could be *anything*
<pixelherodev>
*but*, for any given stream, the functions will always return a specific set
<pixelherodev>
The real solution is to figure out a way to have OutStream(blahblah) coerce to OutStream(anyerror), which I doubt is possible at present
<pixelherodev>
Actually
<leeward>
Is there a roadmap somewhere for generally what features are planned for 0.6 and 0.7?
<pixelherodev>
What about a function `OutStream.toAnyerrorStream()` which returns an OutStream(anyerror)?
<pixelherodev>
0.6 roadmap is in 0.5 release notes
<pixelherodev>
Beyond that, check the milestones on GitHub for a general idea
<leeward>
I thought I saw it somewhere.
<andrewrk>
also look for issues which have label:accepted
<leeward>
Yeah, the milestones on GitHub are where I was looking.
<pixelherodev>
Might I suggest closing #3898? As I mentioned within, it's not actually a bug, it's the compiler's type checking not being strict enough (which AFAIK has been reported elsewhere many times)
<andrewrk>
pixelherodev, it's always a bug if llvm ir verification fails. I don't mind keeping duplicate bug reports open, just in case, plus when they pile up it puts more pressure to solve them. sometimes they're not duplicates even when they seem like they are. I do like to run the reproduces to make sure
<pixelherodev>
makes sense
<pixelherodev>
Whelp, I'm going to get started on my work on stage1 this weekend
<pixelherodev>
Got a couple bugs I want to fix
<pixelherodev>
If I feel I'm comfortable with it at that point, I'll see if I can fix the uncaught-errors-leads-to-broken-IR thing
<companion_cube>
pixelherodev: you need to be able to have a variable for the error set, I think, to be able to talk about it
<companion_cube>
even in generic contexts
<pixelherodev>
Right but that variable already exists
<pixelherodev>
OutStream.Error
<pixelherodev>
Hmm...
frmdstryr has joined #zig
<pixelherodev>
Idea: OutSream.toAnyErrorStream(self: outStream) OutStream(anyerror) which returns an OutStream(anyerror) initialized with the same values as the original