<andrewrk>
I think I briefly went over this point in the discussion here
<Snektron>
That would work also
<Snektron>
But then you need a way to express the pointer type of a pointer
<fengb>
I feel like I’m derailing everyone with silly goose chases
<Snektron>
pretty much
<Snektron>
but its 2 am and im bored anyway
* andrewrk
crosses fingers for cpu features tests to pass
<andrewrk>
I got the true zig experience today: went down a really promising path that involved comptime, got super close to being done, then hit a brick wall of compiler bugs
<Snektron>
I can relate to that
<Snektron>
Every time i push my friends into Zig i get "that language where the compiler crashes every few seconds?"
<daurnimator>
mikdusan: ah yep
<daurnimator>
mikdusan: any idea what might be causing the trace to be so.... wrong?
<mikdusan>
it smells like a similar situ with build_runner, where it accumulates stack traces that are handled as returns and not errors
<mikdusan>
I'll try to find PR
<andrewrk>
Sahnvour came up with a nice (accepted) proposal to solve this
<mikdusan>
each such test involving `error.Something` has a proportional effect on stack trace
quetzalb has joined #zig
<quetzalb>
commit 7a1cde7206263c8bb3265c225ed4213d1b7bdb58 seems to have introduced build break for me (Assertion failed at /home/qbradley/src/zig/src/analyze.cpp:7624 in get_builtin_value)
<quetzalb>
break on x86-64 ubuntu
<plumm>
fengb: i would gladiator battle the guy who owns nick on here
quetzalb has quit [Remote host closed the connection]
<andrewrk>
argh, on sr.ht sys::getHostCPUName() reports "athlon-xp" as the native cpu, but clang says "unknown target CPU 'athlon-xp'": https://godbolt.org/z/hH-n7p
<andrewrk>
and llvm says "LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!"
<andrewrk>
ok I think llvm is simply incorrect about the cpu name
<andrewrk>
sys::getHostCPUName() reports athlon-xp which is a 32 bit cpu, but sys::getHostCPUFeatures() reports an inconsistent list with this, including +64bit
<andrewrk>
ugh, now I have to write code to work around llvm giving the wrong answer for the native CPU
<BaroqueLarouche>
andrewrk: any reason why std/elf.zig use extern enum and extern struct ?
<andrewrk>
yes these structs are memory-compatible with the ELF format
<andrewrk>
you can mmap and @ptrCast for example
<BaroqueLarouche>
packed struct should do the same job no ?
<andrewrk>
it would be more verbose to do that. the ELF structs adhere to the C ABI by design
<BaroqueLarouche>
got it
sammich has quit [Remote host closed the connection]
<daurnimator>
andrewrk: thoughts about using a distinct type for fd_t?
<daurnimator>
something like `pub const fd_t = enum(u32){_};` could even add methods on it.....
<andrewrk>
we have fs.File
<daurnimator>
true... but we use fd_t in os.zig
<daurnimator>
I feel like it could prevent mistakes if you e.g. were unable to accidently pass a length as an fd
<daurnimator>
Same with pid_t
<fengb>
I’m in favor. In Elm I learned to wrap record ids and it prevented accidental mixing of very similar types
<fengb>
Also, stdin/ stdout/ stderr should be named enum members right?
<TheLemonMan>
I'll have a look at the skylake problem later, I'm a bit in a hurry right now
<TheLemonMan>
yeah, there's no need to overcomplicate it
<andrewrk>
fair, thanks for the help
<andrewrk>
aarch64 and windows are still a mystery
<TheLemonMan>
the windows thing was fixed in LLVM10 last time I checked
<andrewrk>
ok I can test in the llvm10 branch, which needs to be updated
mahmudov has quit [Read error: No route to host]
<andrewrk>
the branch happened btw
mahmudov has joined #zig
<TheLemonMan>
wrt the fast_gather stuff, I suppose that setting the cpu name also sets a bunch of base features
<TheLemonMan>
the cpuid code covers only a few of them
<TheLemonMan>
you should ask the LLVM devs if that's the case and/or check out what clang does when you specify the "native" arch
<andrewrk>
so the correct set of features would be the longer set corresponding to the known cpu features
<andrewrk>
ok I'll ask
<TheLemonMan>
it depends, if your cpuid reports you have no AVT (eg. you're on a VM where it's been disabled) you shouldn't blindly take _all_ the supported features for you target arch anyway
<andrewrk>
that would be an argument to not revert cbe9a51
<fengb>
Tangentially related: would it be useful to build a fat binary that can detect features at runtime and swap out the implementation?
<TheLemonMan>
hah "FIXME: We should also incorporate the detected target features for use with -native."
<andrewrk>
now there is some evidence for my argument that we have something to gain from self-hosting native CPU detection :)
<fengb>
Ahhh cool
<andrewrk>
fengb, the broader topic here is making a binary that is as portable as possible. it would be interesting to try to make an ELF binary that had multiple OS and arch implementations of the same thing. universal binary
<andrewrk>
that might be silly, but it does simplify things for the user if they don't mind a few extra bytes on their hdd
<andrewrk>
this use case is valuable to game devs
<fengb>
Yeah Apple did it with the 64bit transition and it seemed to work pretty well
<andrewrk>
also idk the PortableExecutable format very well yet, but it's possible you could do a thing like pdf/zip where you make something that is both an elf and a .exe
<pixelherodev>
I'd considered it, but the fasted to implement was literally just `cat`
metaleap has joined #zig
<pixelherodev>
`cat png rom >jointfile`
<TheLemonMan>
andrewrk, check out `getFeatures` in MCSubtargetInfo.cpp
<pixelherodev>
andrewrk, rightyo
<TheLemonMan>
it picks all the features from the specified cpu and then it applies the +/- modifiers specified by the feature string
<TheLemonMan>
I guess that if you don't specify any target cpu then it's on you to pass the correct feature set
_Vi has quit [Ping timeout: 248 seconds]
* andrewrk
looking
dddddd has quit [Ping timeout: 265 seconds]
<andrewrk>
I think we should keep cbe9a51
<andrewrk>
self-hosted native target detection can hopefully be improved to return a value that more strongly indicates "the cpu is 'xyz' and you can trust that it has all the expected features"
<pixelherodev>
Well, it can do a CPUID test against all expected features
<pixelherodev>
Seems pretty trivial to implement
<andrewrk>
in the sr.ht environment, it would detect the model/features mismatch and return something like "cpu is unknown; feature set is xyz"
<pixelherodev>
Or `CPU self-reports as XYZ but lacks XYZ features ABC`
<pixelherodev>
I feel like that list will typically be smaller and easier to read
<TheLemonMan>
cbe9a51 is wrong. If the cpu has 'a,b,c' and LLVM feature detection returns '-c' what does it return?
<andrewrk>
sorry I misunderstood the question. that doesn't happen, llvm feature detection specifies all the features, + or -
<andrewrk>
do you have evidence to the contrary?
<TheLemonMan>
not really, the target detection code for x86 specifies only a handful of them
<pixelherodev>
Question
<pixelherodev>
Is the goal to match the LLVM behavior?
<andrewrk>
so it should take the cpu features, and then add/remove features from the set?
<pixelherodev>
That is, should I do a straight up port?
<TheLemonMan>
...namely only the few ones that may or may not be available, hence the cpuid test
<pixelherodev>
Or should I implement detection of *all* features via e.g. CPUID?
<pixelherodev>
I can do either one
<andrewrk>
the goal is to do what makes sense according to hardware, with the knowledge that we do have to be able to translate this info to a format that llvm understands
<TheLemonMan>
llvm is already doing that for you, if you want to do the intersection yourself you're welcome to do so
<andrewrk>
TheLemonMan, are you suggesting to change the data layout of std.Target.CpuFeatures?
<andrewrk>
in the branch it's a tagged union: baseline, a specific cpu, or a feature set
<TheLemonMan>
the algorithm is: if (target == "native") { cpu_name = host_cpu_name(); cpu_features = host_cpu_features(); }
<pixelherodev>
Why do we care about name at all, other than reporting to user?
<TheLemonMan>
the name sets the base profile
<pixelherodev>
Isn't it always better to do proper detection of CPUID bits though?
<andrewrk>
cross compiling
<pixelherodev>
Talking specifically about native compilation though
<TheLemonMan>
you also telling LLVM what microarch you're targeting and that heavily influences the codegen
<pixelherodev>
Why does host_cpu_name need to exit?
<TheLemonMan>
the cost tables are different and so on...
<pixelherodev>
Right, but feature - ohh right
<pixelherodev>
It's not just about feature presence, it's about feature cost, which varies dependent on HW
<TheLemonMan>
yeah not only that, there are several erratas and various bits of trivia that affect different cpus in different ways
<andrewrk>
TheLemonMan, ok sounds like CpuFeatures should be actually a struct, with a cpu always specified (maybe it is baseline), and feature set always specified
<andrewrk>
the target "triple" could be improved to handle features like that gcc page shows: aarch64+v8_5a-linux-musl
<andrewrk>
this would allow std.Target.Arch to be an enum rather than a tagged union
<TheLemonMan>
(I haven't read yet the patchset) is it a bitset right now?
<andrewrk>
std.Target.Cpu.Feature.Set is a bit set; that part works fine. std.Target.CpuFeatures is a tagged union of {baseline, *const Cpu, Cpu.Feature.Set}
<pixelherodev>
4
<pixelherodev>
woops. ignore that
<TheLemonMan>
I think it'd be less clunky if the baseline features were already "folded" into the feature bitset
plumm has quit [Ping timeout: 265 seconds]
<andrewrk>
yes I think that is the way forward here, so it becomes a struct of *const Cpu, and then the bitset has the cpu features, with the + and - adjustments added to it, and dependencies resolved
<TheLemonMan>
as a end-user I only care about what's available for my binary, reasoning about the feature hierarchy is slightly distracting
<TheLemonMan>
that sounds good
<pixelherodev>
Dependencies?
<pixelherodev>
Ahh, like AVX512 -> AVX256?
<TheLemonMan>
oh dependencies, right... do we have something that checks for dependency violations?
<companion_cube>
the stdlib docs don't point to the source code?
<andrewrk>
so you will be able to do: if (comptime std.Target.current.hasCpuFeature(@enumToInt(std.Target.aarch64.fp_armv8)) {
<Snektron>
Should `&.{}` be valid?
<Snektron>
In this case when converting to a slice
<TheLemonMan>
that's quite a moutful heh
<pixelherodev>
Why is hasFeature int and not enum?
<pixelherodev>
Worst case, the @enumToInt can be done in the function
<andrewrk>
Snektron, yes I think probably. I'm guessing you're trying to use the std.fs.path api
<pixelherodev>
No need for the caller to have to depend on it
<pixelherodev>
s/depend on it/call it manually
<pixelherodev>
That makes it slightly less of a mouthful
<andrewrk>
TheLemonMan, I didn't implement dependency violation detection in this branch
<TheLemonMan>
I think I've answered on hryx's ticket
<andrewrk>
ah
<andrewrk>
ok I'll look at that issue (after cpu features) and try to get it to either closed or accepted by end of week
<metaleap>
when i `os.exit(code)` directly from my `main` does its `defer` still run? unlikely but thought i'd doublecheck. in go it wouldnt for example. reckon the underlying syscall tends to kill , given that i see an `unreachable` in std/os/linux.go#exit
<metaleap>
nevermind saw that `fn main` can return `u8` so will assume thatll be the exitcode
<Snektron>
multi level pointers in c are so weird
<Snektron>
const T**
<Snektron>
i keep forgetting where to place the const
<Snektron>
at least its better if you write `T** const`
<shachaf>
Those aren't the same, though.
<shachaf>
Someone once told me to think of const as a subscript applied to *, as in "T *_{const}".
<shachaf>
That spiral thing is way more complicated than you need to read C declarations and I think it's also not really correct.
<fengb>
One thing that’s weird in Zig is pointers to namespaced values feel backwards
<shachaf>
C declarations use the same syntax as C expressions. It's not really an ideal syntax but it's internally consistent.
<fengb>
I typed `std.mem.*Allocator` on cruise control
_Vi has joined #zig
<metaleap>
so a sugar question/notion. we can `if` on optionals and errs with the 'then' case getting the good-path value and the 'else' case for the "bad" path. ever considered being to invert via the ("technically only bool right now") `!` operator? sometimes could be more readable for multiple nestings where the "bad path" is short (but not empty) until finally arriving after multiple subsequent ifs at a fat "good path"
<metaleap>
well thats still "good path first (possibly bulky) bad path last (brief)", i was asking about for the `if` syntax the possible idea/notion of inverting the order via !-operator .. although on 2nd thought could be detrimental for later reading such code and assuming a bool from the `!`. so scratch that
<metaleap>
so nvm
<fengb>
Let's introduce the `unless` keyword! 🙃
<companion_cube>
`!x or whatevs`
<TheLemonMan>
you can also use a switch
<Snektron>
considering the null-terminated pointer type, is there a more appropriate type than [N]u8 for a null terminated char array at most N bytes?
<metaleap>
no, no more keywords, lets just drop the matter, was fluff :D 80% of readability is outsourcing-into-rightsized-funcs rather than more sugar, i fear. i'm just always easily tempted by the latter (the syntax kind =)
<fengb>
I'm joking. I hate the unless keyword
<andrewrk>
perl was my first scripting language :)
<andrewrk>
side note: I love that you can change `union(enum)` to `struct` in zig, and everything still makes sense, but you get some "missing field" errors
<companion_cube>
crystal also has `unless` I think
<fengb>
10 years into Ruby and I still can't process "unless" without changing it into "if not", and it's largely impossible to read with any compound operator
<companion_cube>
I barely played with crystal but I think I found `return unless …` or `raise unless …` pretty cool
<adamkowalski>
andrewrk: what would you think about changing the semantics of .? Right now it tries to unwrap the optional, but I feel like if it doesn't succeed shouldn't it return an error?
<adamkowalski>
then you have to write const value = try optional.?;
<andrewrk>
(foo orelse return error.Bar)
<mikdusan>
fengb: actually I appreciate ruby's `unless` sugar, especially for trailing if syntax
<adamkowalski>
What is the use case for .? in production code? That seems rather scary right now, since it's essentially just an assumption that it is safe
<andrewrk>
if you have deduplicated data
<andrewrk>
e.g. if you proved 2 lines ago that it's not null
<andrewrk>
for example try writing how to compare two optional ints for equality
<andrewrk>
never mind the open proposal to make the language support it :)
<adamkowalski>
well how did you prove they were non optional in the first place?
<adamkowalski>
then you could do it like so
<adamkowalski>
const x = try optional_x.?;
<adamkowalski>
const y = try optional_y.?;
<adamkowalski>
const result = x == y;
<andrewrk>
try my exercise- write actual code to do it
<Snektron>
except now your optional compare returns an error
<adamkowalski>
Snektron: as oppossed to what? Would you prefer to return false instead?
<Snektron>
oh wait, i forgot about the null == null case
<adamkowalski>
in haskell you use applicatives
<adamkowalski>
(==) <*> (Just 5) Nothing
<Snektron>
I use .? everywhere in the code im currently writing, but i followed the build.zig principe
<andrewrk>
adamkowalski, use a paste site plz
<Snektron>
cause its intended as a tool so never to be run outside of debug mode
<adamkowalski>
sorry, will do
<Snektron>
It seems to me that adding such a try optional.? method would result in rewriting .? as `x.? catch unreachable`
<Snektron>
While the point of .? was to provide syntactic sugar over `x orelse unreachable`
<adamkowalski>
yeah, which I would prefer? It means everytime somebody makes an assumption about validity there is a trail of unreachable
<adamkowalski>
I can grep for a single word and validate my whole codebase
<fengb>
How difficult is Kotlin's narrowing types?
<andrewrk>
basically all of kotlin's narrowing types is planned, if you use const instead of var
<fengb>
Oh neat
<andrewrk>
well let me slow down. at least awareness of integer ranges are planned in this way, to allow coercion
<andrewrk>
and zig already does a little bit of this to avoid bad codegen when we know something is not an error at a return site
<andrewrk>
anyway it is planned for const values to have extra info that the type system is aware of
<adamkowalski>
I saw in the roadmap for 0.6 that the proposal for let instead of const is approved. Is that still gonna happen?
<adamkowalski>
I kindof like the symmetry of const declarations and const in type signatures. Having let for declarations and const in types seems a little strange
<adamkowalski>
Unless const is the default and you need to write mut everywhere you want it
<metaleap>
Snektron: "`return (x orelse return false) == (y orelse return false);` --- oh wait, i forgot about the null == null case" --- no you didnt. (if null then false == if null then false) -> false == false -> true
<betawaffle>
does an array of u1 have the in-memory representation i would expect, or is there a bunch of padding?
<Snektron>
metaleap, the return exits the function, not the expression parenthesis
<TheLemonMan>
betawaffle, each element is padded to 1 byte
<adamkowalski>
betawaffle: look at packed structs if you want somethign different
<betawaffle>
is there a plan to support bit arrays of some kind? like packed structs and such?
<betawaffle>
oh, i wasn't talking about packed structs, i was saying "like packed structs" as in, bit arrays in the same way that packed structs _work_
<Snektron>
if you use u1 as int type you can use it as bit array
<Snektron>
same with structs for bit fields
<betawaffle>
Snektron: that's what i was asking
<andrewrk>
it's weird that the second part of the triple is called "arch". it should be called "cpu"
<andrewrk>
arch would be a sub-field of cpu
<TheLemonMan>
isn't the second part the os?
<betawaffle>
don't cpus belong to an arch?
<andrewrk>
sorry, the first part
<andrewrk>
it's information about the cpu. the arch is only one piece of information about it
<betawaffle>
oh i see what you mean
<andrewrk>
not going to make that change in this branch, but this "data in the wrong place" situation will become more apparent
<TheLemonMan>
well it's still an architecture, you don't have pentium4-linux-gnu
<TheLemonMan>
the cpu is out-of-band data wrt the triple
<andrewrk>
pentium4-linux-gnu would be even more descriptive than i386-linux-gnu
<andrewrk>
it's an unambiguous, actually preferable triple
<andrewrk>
since it gives all the cpu features you want too
<betawaffle>
what would you use to build something for 16-bit or 32-bit mode? just a different cpu?
<pixelherodev>
Someone mentioned a pointer-to-any type, and the consensus was c pointer to c void - I'd contend that it's better to just use a `usize` for that and use `intToPtr` to obtain the desired type
<andrewrk>
my actual proposal would be to support the syntax like gcc, e.g.: aarch64+v8_5a+bti-linux-musl
<andrewrk>
the `-` are a problem to solve however
<pixelherodev>
`_`?
<pixelherodev>
Could either use `_` for the feature `-`, or the triple separator
<andrewrk>
there is a _ in that feature
<pixelherodev>
e.g. `aarch64+v8_5a+bti-thingy_linux_musl` oh wait yeah
<pixelherodev>
`:` separator?
<pixelherodev>
or `;` or something
<pixelherodev>
But I feel like `:` is less likely to result in people accidentally running `linux` as a command :P
<andrewrk>
the benefit of c_void (which is proposed to rename to anyopaque btw) is that the type keeps track of alignment. but if you don't want that, probably usize is easier
<Snektron>
imagine the "triple" for x86 cpus
<andrewrk>
mostly I'm just talking about the data layout of std.Target
<Snektron>
would be more like a googol with all those extensions
<andrewrk>
pixelherodev, alignment and const
<adamkowalski>
andrewrk: is there a way to concatenate anonymous list/structs?
<andrewrk>
++
<andrewrk>
it's new; you might find bugs
<adamkowalski>
ah that would only work with compile time known data right
<adamkowalski>
Is there any way to have a heterogenous list at runtime without having a pointer idirection for each element, or using some other form of type erasure?
<betawaffle>
you mean like a struct?
return0e has quit [Remote host closed the connection]
<metaleap>
with variable length i guess =)
<adamkowalski>
The use case is that I want take the gradient of an expression with respect to some parameters. All the parameters are nd arrays (tensors) which have an elemnt type and a rank. I don't want to throw that information away since it's useful to type check operations like addition (you don't want to allow addition between matrix and vector)
<pixelherodev>
andrewrk, ah, fair
<andrewrk>
++ will concatenate a tuple together which has runtime values, constructing a new tuple
<adamkowalski>
so I need to return to you a "tuple" of tensors where each one can potentially be a differen type, but it's all based on the types of the inputs you give me. They should match
<adamkowalski>
okay I'll see if I can make that work, thanks
<adamkowalski>
also once the proof of concept is done I need to come up with an idea to demonstrate the library, thats trivial enough to be easily understandable quickly. But complicated enough to show how the library works in depth. Is handwriten digit recognition still okay, or is that so overdone that it's boring?
return0e has joined #zig
<fengb>
wasm opcodes are so much easier to work with than Z80 >_>
<pixelherodev>
... z80 is really easy
<pixelherodev>
What are you talking about
<fengb>
Half the op codes are loads. Really hard to name and keep track
<pixelherodev>
meh
<companion_cube>
have y'all heard of serenity OS? it's quite amazing
<fengb>
We're still struggling with IO a year later ;)
<companion_cube>
seems like you can actually be productive with C++ :D
<edr>
I have been watching him for a while, has a ton of youtube content of him working on it, and also does "commute talks" that are typically very good
<Snektron>
nobody said you can't
<fengb>
All good compilers begin their life in C++ 🙃
<companion_cube>
nah, some started in lisp or ocaml :-°
<fengb>
And... I didn't mean that as a backhand to Rust >_>
<Snektron>
I'd pick c++ over most other languages tbh
<fengb>
Subsets of C++ can be good. The problem is no 2 people chooses the same subset
<andrewrk>
sometimes I don't even choose the same subset as myself
<companion_cube>
andrewrk: once Zig 1.0 is reached, we all know someone will RIIZ serenity OS
<companion_cube>
in 6 months :p
marmotini_ has quit [Remote host closed the connection]
<Snektron>
Just pick anything but macro's tbh and you're good
<pixelherodev>
Heh, I already have a different base kernel I could use for that :P
<adamkowalski>
fengb: I feel like there is a consensus now though. The transtition from c++11 -> 14 -> 17 -> 20 made many things way better. People don't really use inheritence anymore, it's mostly static polymorphism with concepts and template meta programming is transtitioning to using constexpr. Runtime polymorphism is handled by type erasure. Smart pointers for owner ship, etc
marmotini_ has joined #zig
<fengb>
I don't understand half those words >_>
<companion_cube>
wait, concepts are released??
<BaroqueLarouche>
coming soon, some compilers have partial support for concepts
<adamkowalski>
yeah they are part of the c++20 standard. clang just merged to trunk, but had a forked version working for over a year. gcc has had them forever.
<fengb>
C++98 or bust 🙃
<adamkowalski>
fengb: we use most of what they use in zig too. constexpr allows a function to be evaluated at compile time, just like Zig
<BaroqueLarouche>
errgh no, C++11 fix so many warts
<adamkowalski>
concepts are compile time enforced properties on types
<Snektron>
c++98 gives me anxiety
<adamkowalski>
so rather then passing things by template (compile time duck typing) you can say I want any type that supports these operations
<companion_cube>
c++ is trying to catch up with rust
<Snektron>
adamkowalski, i think you use concepts with templates no
<Snektron>
template <Concept T>
<adamkowalski>
yeah
<adamkowalski>
but they add requirements on the type T
<adamkowalski>
so like SFINAE
<Snektron>
still templates
<adamkowalski>
they participate in overload resolution
<adamkowalski>
of course, templates are the mechanism for static polymorphism, It just allows you to constrain the type being passed in
<adamkowalski>
I think we could use something like that in zig, so rather then var you can reason about the type you expect
<Snektron>
There was a proposal for zig-like templates with constexpr parameters
<Snektron>
i doubt it'll be added though
<adamkowalski>
I don't know if we need templates
<companion_cube>
it's just like rust's traits
<adamkowalski>
we have first class types
<adamkowalski>
I think the simplest thing is to allow a predicate (a function which takes a type and returns a bool) instead of var
<Snektron>
there was a proposal for that
<adamkowalski>
if you call a function which constrains it's parameter type with a predicate and it returns false, it's a compile error
<Snektron>
but the thing is that Zig doesn't have any overloading
<adamkowalski>
Snektron: yeah I know, I'm just saying I think it's a good idea
<Snektron>
So you can implement that simply with a debug
<Snektron>
assert
<fengb>
We can do comptime traits
<adamkowalski>
sure, but in my opinion it's a good idea to document your requirement in the type signature
<adamkowalski>
this will help with reading other peoples code.
<Snektron>
yeah i agree with you on that
<adamkowalski>
companion_cube: template constraints are D's version of concepts. However, they don't allow you to overload on them as well as they should
<Snektron>
anyway, i had a cheeky thought about defining traits in userland
<companion_cube>
maybe, it just sounds like what you said
marijnfs has joined #zig
<adamkowalski>
For example if I have two functions one which takes a random access iterator, and one which takes an forward iterator, D's template constraints would say it's ambiguious
<Snektron>
With tuples you can define an interface pretty neatly
<adamkowalski>
in c++ you would go with the the random access iterator function since it's more specialized
<companion_cube>
adamkowalski: in zig you'd comptime if inside the body, right?
<companion_cube>
it's not like Zig has overloading anyway
<adamkowalski>
yeah here we would do an if of a switch statement
<companion_cube>
so I think it's fine :p
<adamkowalski>
you just need to make sure to check them in reverse order of specialization. So if two compile time traits could have matched, you want the most specialized version in the top most if statement
marmotini_ has quit [Read error: Connection reset by peer]
marmotini_ has joined #zig
Akuli has quit [Quit: Leaving]
marmotini_ has quit [Ping timeout: 268 seconds]
<metaleap>
adamkowalski: "I just wish we had a way of documenting minimal requirements of a type being passed in rather than just writing var" --- i'll attack numerous code-analysis/annotation things (aka extra derived code intel that can be rendered into docs or into one's not-too-bare-bones code editor) in the medium-term future and this is one of them. zig with comptime `type`-"driven" branching combined with being able from parsed-asts to see how things are
<metaleap>
passed on (or dot-accesses) makes this more tractable than macro-driven langs or langs that have merely-to-be-runtime-inspected `object`/`any`/`interface{}` functionality. i need such myself anyway, and it allows for much wider scope of linting depths. the next few months will occupy my little free time with such
<metaleap>
sure you'll get supremely-verbose (dang turing completeness) "type descriptors" that way but then it's all about figuring out how to reduce them neatly while remaining accurate/complete. and aiming for "80% of the time more helpful than confusing" suits most folks immediate/practical concerns
return0e has joined #zig
zfoo_ has quit [Read error: Connection reset by peer]
marijnfs has quit [Ping timeout: 268 seconds]
marijnfs has joined #zig
NynnFr has quit [Remote host closed the connection]
mahmudov has quit [Ping timeout: 258 seconds]
mahmudov has joined #zig
<TheLemonMan>
andrewrk, wrt #4263, that was about stack traces and not compile errors
<andrewrk>
oh!
ltriant has joined #zig
<andrewrk>
merged
<andrewrk>
thanks
<TheLemonMan>
thank you :)
<andrewrk>
alright let's see how this new cpu features commit performs in the CI
<TheLemonMan>
yeah, I cannot be arsed to send a PR to fix that heh
<mikdusan>
ok I'll PR it if you want
<TheLemonMan>
sure thing, thank you
return0e_ has joined #zig
return0e_ has quit [Ping timeout: 265 seconds]
<Snektron>
weird, for some reason std.fmt.format won't call my custom format function
<Snektron>
ah, forgot `pub`
<andrewrk>
TheLemonMan, does the --verbose-llvm-cpu-features output look good in the latest layneson-cpus_and_features commit, for -target aarch64v8-linux-none ?
<andrewrk>
it's passing the tests for me locally but the linux ci is giving qemu: uncaught target signal 4 (Illegal instruction)
TheLemonMan has quit [Ping timeout: 258 seconds]
mahmudov has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
<daurnimator>
andrewrk: re: cpu features: perhaps it should be a ternary: no/maybe/yes. that we can dispatch `if (runningTarget.hasFeature("sse4")) { sse4_code() } else { sse2_code() }` -> the condition could be compile time or runtime.