<fengb>
And the padding... I don't understand how padding works
<fengb>
Oh hey look at that. I think I'll take a stab at this
<scientes>
fengb, if it requires a bunch of cpp, the style is to wrap it to a c api
<scientes>
in zig_llvm.cpp
fengb has quit [Ping timeout: 256 seconds]
scientes has quit [Ping timeout: 257 seconds]
knebulae has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
jevinskie has joined #zig
Aransentin_ has quit []
avoidr has quit [Quit: leaving]
return0e_ has quit [Remote host closed the connection]
_whitelogger has joined #zig
tdc has quit [Quit: Leaving]
jjido has joined #zig
return0e has joined #zig
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
marijnfs has joined #zig
knebulae has joined #zig
<tgschultz>
I think interface reform mark 3 is going to be the one. I've just got one more docgen test to fix and then a little cleanup and the remaining problems will be down to #2501, #2487, and #2515.
<donpdonp>
yet Buffer.initSize(allocator,0) does not appent a null byte to list, so len() crashes
<donpdonp>
BufferZero would be a better name, with a new Buffer that is clean of null business.
Aransentin has joined #zig
scientes has joined #zig
<donpdonp>
hmm initSize does reallloc to (0+1) so might not be buggy after all, but im getting an intoverflow.
return0e has quit [Read error: Connection reset by peer]
Zaab1t has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Client Quit]
wootehfoot has joined #zig
Zaab1t has joined #zig
Aransentin has quit [Quit: Page closed]
Zaab1t has quit [Remote host closed the connection]
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
jjido_ has joined #zig
jjido has quit []
return0e has joined #zig
jjido_ is now known as jjido
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
<tgschultz>
scientes, I think what's being discussed is like the @distinct proposal. like, my function takes an x,y, and z, bu those must be in meters so I create a new type called Meter that's the same as float in reality, but not for type checking.
<scientes>
oh yeah that is good idea, C has that
<scientes>
can't you do that with a struct however?
return0e has quit [Ping timeout: 272 seconds]
<scientes>
Linux depends on that to make uid's distinct for examples, its very important for avoiding security problems
<tgschultz>
yeah, but you'll have to treat it as a struct and access members.
<scientes>
cause I would like to minimize the number of crazy features in zig
<tgschultz>
I'm in the same boat
<scientes>
like @This() is kinda for the lazy
<scientes>
and is confusing
<tgschultz>
@This() is absolutely required, because you can't call a type by name in its own definition if it isn't top-level
<scientes>
oh I C
<tgschultz>
and also a lot of generated types don't even have names.
<tgschultz>
they're just `return struct {...`
<scientes>
maybe we could somehow hack the struct thing to work
<tgschultz>
If we could, I'm not at all opposed to dropping @This(). I don't enjoy the boilerplate of `pub const Self = @This()` on things.
<scientes>
cause i find it excessive that you have to name a union in c, and then the member
<scientes>
well it makes it clearer what is going on that way...
<emekankurumeh[m]>
doesn't zig have a distinct "typeID" for all it's types?
<scientes>
emekankurumeh[m], no, all ints have the same typeID
<emekankurumeh[m]>
but ints have a different typeID than say floats, correct?
<scientes>
yes
<scientes>
how about if a struct only has one member, you can leave off the name, and then it will magically work like we want?
<scientes>
that is pretty hacky
<scientes>
yeah @distinct seems best
<emekankurumeh[m]>
creating structs seems to indicate that "allocating" typeIDs is somewhat trivial, so could a distinct builtin just allocate a new typeID with the same underlying type?
<scientes>
emekankurumeh[m], all structs have the same zig type ID, and it isn't trivial, in fact LLVM is going to change how it works in the future with pointers
<scientes>
emekankurumeh[m], but sometimes you want stuff to implicitely cast
<scientes>
the problem we are talking about is bikeshedding about the syntax
<emekankurumeh[m]>
i thought zig had its own typeID system.
<scientes>
it does
<scientes>
but that doesn't mean it doesn't use LLVM"s as well
wootehfoot has quit [Read error: Connection reset by peer]
<donpdonp>
$ zig test src/oneFile.zig is actually convenient enough to use. #winning
<emekankurumeh[m]>
but why would this need to extend to llvm as well@
<scientes>
it doesn't
<scientes>
nor does it in clang
<scientes>
the real issue here however is not the compiler
<scientes>
its a bikeshedding issue
<scientes>
god i hate autotools
<emekankurumeh[m]>
hmmm, since the proposal wasn't accepted yet I thought there was some other issue with distinct types
<scientes>
emekankurumeh[m], there is a lot of work to do
<scientes>
please contribute
<scientes>
but maybe start on something a little less involved first
<scientes>
like something user-space
<scientes>
emekankurumeh[m], it would probably keep the same TypeID so that the compiler doesn't break
<scientes>
but gain a new internal field special for type-checking
Sahnvour has quit [Ping timeout: 272 seconds]
Aransentin has joined #zig
Sahnvour has joined #zig
marijnfs has joined #zig
<marijnfs>
hi, i'm trying to find in the documentation what the ! means for return values? Does it mean an error can be thrown?
<jjido>
it separates return type from error set
<scientes>
> Does it mean an error can be thrown?
<scientes>
yes
<scientes>
that's exactly what i means
<scientes>
marijnfs, realize that errors in zig are just syntactic sugar
<scientes>
they are implemented with multiple argument returns
<scientes>
so more like the Linux kernel, than c++
<emekankurumeh[m]>
I don't think it should be too hard. I've done some work on the compiler before and it wasn't too bad
<emekankurumeh[m]>
i should probably wait until the proposal is accepted though
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marijnfs>
scientes: thanks, yeah its nice that its clear about that
hio has joined #zig
<marijnfs>
it.peek().?.id
<marijnfs>
what's that question mark in a member call