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…]
<GitHub129>
[zig] alexnask opened pull request #972: Fixed inlining determination test (master...nested_func_comptime) https://git.io/vpucC
<bodie_>
Can you compose structs with anonymous members like in Go?
<andrewrk>
bodie_, there's a bug in valgrind right now that makes debug symbols not work for zig programs (as well as clang + lld programs), but there's a command line option for zig you can use as a workaround
<Hejsil>
t that something like this: struct Some { (Other); ... }
<Hejsil>
Basicly you get all the fields of Other in Some
<Hejsil>
And can pass Some to functions taking Other
<bodie_>
yes
<bodie_>
not the last bit
<bodie_>
that is interfaces
<Hejsil>
Ye sure?
<bodie_>
Haha, yes.
<Hejsil>
Because, why shouldn't that work
<Hejsil>
:)
<bodie_>
Because Some is not an Other.
<Hejsil>
But it has the a part of it which is the same memory layout
<bodie_>
If Other implements interface I, then so does Some, so you could pass Some to f(some I) and it would work, because it would construct an I containing the Some at that time.
<Hejsil>
I don't know enough Go
<bodie_>
it's not hard to learn and definitely fun to use!
<Hejsil>
I would just assume you could pass Some to Other
<Hejsil>
Gee, I'll stay with Zig
<Hejsil>
Tried Rust, Go, D, C++ and Nim when scouting for a new systems langauge :)
<Hejsil>
Zig just feels right, where the others failed for me in some aspect
<Hejsil>
Like, in Go. Comments can have semantics
<Hejsil>
Which is a no go for me. Comment's don't have semantics!
<andrewrk>
Hejsil, what turned you away from rust?
<bodie_>
Rust tries to do better than C++, but it is almost less usable than C++ sadly.
<andrewrk>
that's the same conclusion I came to
<bodie_>
You really need to work with the type system.
<andrewrk>
I respect the project a lot
<bodie_>
And it's also not actually all that safe.
<bodie_>
Proof-driven Rust would be a lot cooler
<andrewrk>
why not?
<walac>
funny, just scrapping the Rust docs I came to the same conclusion "Jesus, another C++ bloat, thanks"
<alexnask>
I thought using unsafe blocks is relatively rare for packages that are not really low level?
<andrewrk>
bodie_, oh, you're talking about go interfaces
<bodie_>
andrewrk, well, that example isn't supposed to demonstrate interfaces...
<bodie_>
but it happens to
<alexnask>
Ah, right, thought you were talking about rust too :P
<andrewrk>
bodie_, what is it demonstrating?
<bodie_>
andrewrk, it demonstrates making a type that contains an anonymous type as a field
<andrewrk>
oh I see it - io.Writer
<alexnask>
This is similar to Jai's using
<andrewrk>
I didn't even know go had this feature and I've been using it at work
<Hejsil>
Lol
<bodie_>
it's kind of a kludgy example though because I renamed Write
<alexnask>
Were you can basically have a using foo: Foo in a struct then you can access foo'
<alexnask>
foo's fields directly with dot access
<bodie_>
yes
<bodie_>
it's a convenient and better substitute for the way people usually use inheritance
<bodie_>
easily lets you compose a type out of 5 other types if you want to be dumb like that
<andrewrk>
besides namespacing, is this any different than having io.Writer be a named field inside wc ?
<koomi>
bodie_: I think exactly that sort of method overwriting is super nice
<alexnask>
@andrewrk I'm not 100% sure in Go, but I don't think so
<koomi>
you can easily add some functionality like timouts around any Writer or whatever
<bodie_>
no, it actually is a named field, which has its own name
<bodie_>
I mean its own type name as its named
<bodie_>
name. dammit
<andrewrk>
ok yeah I've thought about this - I think having a name feels more annoying when you're writing code
<andrewrk>
but it's much nicer when reading code
<koomi>
well you can call io.Writer methods on your type
<bodie_>
one thing I've noticed in Go is that certain implicit links between types can cause it to be hard to reason about behaviors
<koomi>
and your type implements all the interfaces of embedded types
<bodie_>
for example the fact that interfaces use duck typing means you need static analysis to know why something is calling Write or how it works
<koomi>
so that's a big advantage to having at as a normal named field
<andrewrk>
you could call io.Writer methods if it had a name: wc.writer.Write
<bodie_>
yes, in the example you can see it calls by name in the Write "overload"
<alexnask>
Basically you can implicitely cast to the embedded type right?
<koomi>
yes
<bodie_>
not exactly alexnask. the static types don't match, but that's typically where interfaces come in
<bodie_>
e.g. you can pass the wc to fmt.Fprintf
<alexnask>
right, because Fprintf expects an io.Writer
<andrewrk>
I think this is equivalent to having the field have a name, except syntactically you can omit the field name in various places
<alexnask>
but that only works with interfaces?
<bodie_>
what do you use Go for at work?
<andrewrk>
slowly migrating a monolithic c++ website to use Service Oriented Architecture
<bodie_>
In many ways Zig looks like what I would prefer from Go where it really irritates me sometimes
<alexnask>
can you do struct Foo { int } and then add methods to Foo and have it behave like an int wherever it needs to?
<bodie_>
I've been using Go for 5 years now and I'm getting pretty bored lol
<andrewrk>
getting bored of a language actually kinda seems like a complement to the language to me
<bodie_>
alexnask, correct
<bodie_>
um
<andrewrk>
I will never be bored of C++, I will continue to be frustrated by it every day I have to use it
<bodie_>
not quite on builtins
<bodie_>
sorry "yes" was a reply to "that only works with interfaces"
<alexnask>
@odie_ Gotchab
<bodie_>
because Foo isn't Bar, even if they're both Writer
<bodie_>
sorry neither Foo nor Bar "are" Writer but they implement its methods so a Writer may be constructed using either of Foo or Bar.
<bodie_>
I was trying to come up with a tiny language to implement generic types for Go and it is _extremely_ similar to the comptime zig stuff but way more rudimentary
<bodie_>
comptime is sweet af
<alexnask>
yeah
<Hejsil>
comptime is the best way to crash the compiler :)
<bodie_>
lol
<andrewrk>
lol
<andrewrk>
I hope that will not be true forever
<bodie_>
how hard is it to build master zig on windows?
<andrewrk>
bodie_, there are step by step instructions in the wiki
<bodie_>
"master zig" sounds like some zen robot guru from the Mega Man universe lol
<Hejsil>
andrewrk, well comptime is just evaluating Zig ir, and that's probably always be one of the biggest parts of the compiler
<bodie_>
andrewrk, regarding C++ frustration, I agree, but it is boring in the way that it would be boring to have to draw with crayons for work every day
<bodie_>
alexnask, regarding your int question, you would do that by aliasing int, type Foo int
<bodie_>
I'm not trying to get too into Go conversation here though lol just curious about anonymous composition
<alexnask>
Right, was just curiouus how Go handled it exactly
<andrewrk>
bodie_, I see what you mean, that's a fair way to put it
<andrewrk>
Hejsil, we'll get there. It's a finite set of bugs
<Hejsil>
:)
<alexnask>
@andrewrk Is comptime @ptrCast, @ptrToInt, @intToPtr support planned?
<alexnask>
It sounds pretty much impossible to do
<koomi>
one more thing re. embedded types in go: it's different from having a named field in that the embedding type inherits the interface implementations
<koomi>
you could of course write wrappers for all the methods
<koomi>
but with struct embedding you can easily extend other types with a constant amount of work
<bodie_>
it is really convenient for separation of concerns to compose a bigger type out of anonymous interfaces
<koomi>
yeah
<koomi>
it's a neat way to get some inheritance-style composition without all the object-ortientation blabber
<bodie_>
I've been moving more towards value types and just using packages for namespacing what would have been methods though
<bodie_>
I think a lot of OOP is just trying to solve namespaces
<bodie_>
then your "bigger type" is more like a function that calls package funcs on locally scoped values
<bodie_>
you don't need many interfaces that way either
<bodie_>
types with big method sets are evil
<bodie_>
the AWS api package is truly godawful
<bodie_>
sorry for dragging this so offtopic andrewrk :P
<koomi>
haven't used the aws api but generally I think I agree
<koomi>
getting back to zig
<koomi>
has someone used the kvm api from zig yet?
<koomi>
I think it would make a good test case for dealing with systemsy C APIs
<koomi>
lots of ioctls, lots of passing memory around, a memory-mapped fd containing a struct with a union
<Hejsil>
Uuuh! This is valid: @field(error, "SomeString")
<Hejsil>
Time to generate error sets
<alexnask>
lol
<alexnask>
Nice
<alexnask>
And I was actually wondering if it were possible earnlier
<andrewrk>
alexnask, @ptrToInt and @intToPtr will never work at comptime. @ptrCast can work sometimes
<andrewrk>
e.g. if your pointer is to comptime memory, we could make that work
<alexnask>
Right I can see how it could work for integer, floating point types
<Hejsil>
I think I found a bug
<alexnask>
It would be impossible for structs right?
<andrewrk>
alexnask, it should be possible for packed structs and extern structs
<andrewrk>
since those have well defined layouts
<alexnask>
I thought the fields of a comptime struct value were represented in different ConstExprValues?
<andrewrk>
they are, which is why we currently do not support comptime @ptrCast
<andrewrk>
we would need a more complicated comptime value data structure
<alexnask>
Aah ok when you talked about the well defined layout I was wondering if I missed something
<andrewrk>
alexnask, yes, sorry, sometimes I do not make it clear whether I am talking about status quo or "in theory when zig is done"
<alexnask>
Well, in theory then @ptrToInt and @intToPtr could work too, no? If we assigned a unique integer id to each pointer value and coold look up the pointer through the integer
<Hejsil>
Ooh wait. No that's not a bug
<Hejsil>
lol
<alexnask>
Then see if we can cast it to the type @intToPtr requested
<andrewrk>
alexnask, I don't think that makes sense to do
<andrewrk>
if we were going to make those functions work at comptime, we would need to coordinate with the linker and know the address they would be at
<andrewrk>
otherwise you could save @ptrToInt() and then at runtime @intToPtr() and it would be wrong
<andrewrk>
I'm trying to think if Address Space Layout Randomization is relevant here
<andrewrk>
btwwe actually do support @intToPtr at compile time, as long as you don't deref it
<alexnask>
Obviously a custom preprocessor is horrible :P
<andrewrk>
or even just the normal preprocessor :)
<alexnask>
Right :p
<Hejsil>
It's always to tempting just to "Write a macro"
<Hejsil>
What's the worst that could happen
<bodie_>
throw more ripgrep at it
<bodie_>
what are you trying to accomplish with your error set?
<Hejsil>
I want to generate an error set from a enum I got from C
<Hejsil>
And the generating a mapping from the C enum > error set
<bodie_>
does @typeInfo work on C types? alexnask
<alexnask>
In my case I thought about a library that can decode any struct on top of the JSON library that is currently proposed through the PR, and it would be nice to be able to error out with a field name
<alexnask>
@bodie_ It works on any type, haven't actually tested it though
<alexnask>
I assume integer types will give Int TypeInfo etc.
<alexnask>
(c_void probably returns an Opaque TypeInfo and not a Void TypeInfo but everything else should be intuitive)
<bodie_>
because void in C doesn't mean the same thing as void in Zig, right?
<bodie_>
aiui, zig void is a zero-sized type
<andrewrk>
bodie_, c_void is defined like this: const c_void = @OpaqueType();
<alexnask>
Right, pretty much (and it's the only type you can ignore an expression of without explicitely doing _ = expr; iirc)
<andrewrk>
I almost think we should translace-c `void *` to `usize`
<andrewrk>
any counter examples?
<bodie_>
what does usize mean?
<andrewrk>
unsigned integer with the same number of bytes as a pointer
<Hejsil>
Readability?
<Hejsil>
void_ptr + 5 now gives a different result
<Hejsil>
Idk
<andrewrk>
hm that's fair
<Hejsil>
What are the reasons for not using &void instead of &c_void ?
<andrewrk>
currently, &void is 0 bytes
<andrewrk>
this is so that you can do something like this:
<Hejsil>
Aaah
<andrewrk>
I don't have a 1 liner. but it's so that you can take the address of 0 sized things and that will compile correctly but result in no code generated
<Hejsil>
Ye, for generic code
<Hejsil>
Got it
<andrewrk>
for example, this will probably work: const HashSet = HashMap(void);
<andrewrk>
wow I found the definition of enqueueEvent. Now I have to figure out which of the 4 overloads, each of which have half the arguments with default values, MyType * is implicitly constructing to one of the parameters
<andrewrk>
boy it would be nice if I knew what argument at the callsite mapped to what parameter of the definition
<Hejsil>
C++. The language that keeps on giving
<bodie_>
I don't want to think about what a C void might be referring to. But if I have to, I think I would like it to BE a usize but READ as a c_void.
<bodie_>
andrewrk, how come calling a fn taking variadic args without any parameters doesn't default to void?
<bodie_>
e.g. HashMap()
<andrewrk>
if you started with 0 parameters, and then add 1 parameter, we want it to be a compile error at all the callsites so you can inspect and potentially fix them
<bodie_>
I actually abuse this in Go to add parameters without breaking my current calls :P
<bodie_>
or for example to define a constructor taking a vararg of optional func configurators
<bodie_>
then you can just Make()
<andrewrk>
zig has a slightly different philosophy, which is that we're willing to trade some pain of typing more and refactoring more, in exchange for a more careful development process that lets you catch bugs
<andrewrk>
for example, if you're adding a new parameter, you might be invalidating the assumptions that were made at some of the callsites
<bodie_>
isn't part of the point of varargs to include noargs?
<andrewrk>
it's probably a good idea to have a quick look at all the callsites and acknowledge the new parameter
<bodie_>
it's *, not +
jjido has joined #zig
<bodie_>
you can't always do that when users are using your library
<bodie_>
in fact, you should never assume that you can go back and change your callsites
jjido has quit [Client Quit]
<andrewrk>
oh I was thinking of normal functions. what does void have to do with var args?
<bodie_>
can you call a fn having only varargs with no args?
<bodie_>
or do you need to pass void
<andrewrk>
yes
<bodie_>
oh ok
<bodie_>
it sounded like you were saying void is required
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Ichorio has joined #zig
<GitHub60>
[zig] Hejsil opened pull request #975: Added better support for none pure enums in translate-c (master...none-pure-enums) https://git.io/vpzF8
jjido has joined #zig
steveno_ has joined #zig
steveno_ has quit [Remote host closed the connection]
<bodie_>
is there a moral or a set of first-principles behind the zen of zig?
<GitHub1>
zig/master 6f002e7 Andrew Kelley: Merge pull request #975 from zig-lang/none-pure-enums...
<GitHub71>
[zig] andrewrk closed pull request #975: Added better support for none pure enums in translate-c (master...none-pure-enums) https://git.io/vpzF8
<andrewrk>
bodie_, it's just my personal opinions. I can expand on them if you like
Hejsil has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ichorio has quit [Ping timeout: 264 seconds]
<bodie_>
sure
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<achambe>
Random optinion, I feel like translate-c combined with being able to import C headers directly are the two most important things for being able to realistically replace C.
<achambe>
opinion*
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<achambe>
keep up the good work
<MajorLag>
It certainly saves a lot of tedium.
<achambe>
being able to import headers definitely means you don't lose anything going to zig. its not a downgrade.
DuClare_ has joined #zig
lorde_kumamon[m] has quit [*.net *.split]
DuClare has quit [*.net *.split]
lorde_kumamon[m] has joined #zig
<andrewrk>
alright, I'm setting up the atomic queue test to run on a loop on my windows laptop and then I'm going to start going through everybody's pull requests
darithorn has joined #zig
<andrewrk>
I've got 4 terminal windows open, running the tests that failed in appveyor, on infinite loops. 10 minutes in and so far I can't reproduce the problem