ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
darithorn has joined #zig
winksaville_ has quit [Ping timeout: 252 seconds]
zolk3ri has quit [Quit: Lost terminal]
donlzx has joined #zig
<karlguy>
hey, what does pub on a type inside a struct do? aka, whats the difference between foo and bar here:
<andrewrk>
I'm starting to think that it might not be a good idea to have private fields after all
<stratact>
why is that?
<andrewrk>
for one, it makes sense, at least in test builds, that you would be able to access al the fields of everything
<stratact>
okay but if you gonna have fields be public by default, at least provide a private option
<andrewrk>
that's probably reasonable
<stratact>
There are time times when designing an API that a user of the API shouldn't know or have to think about some fields but the methods should do the work for them
<stratact>
I'm a fan of encapsulation of course
<karlguy>
Geez, I'm gonna feel like a troll then if I say I agree with andrewrk to not have private fields. :P
<karlguy>
If they were classes, they would make sense, but these are structs, which are meant to represent data structures.
<andrewrk>
maybe what "pub" does for fields is make it so that changing them does not require a major version bump
<andrewrk>
err, *does* require
<karlguy>
Maybe, but that would leak aspects of the built system into the code
<karlguy>
It's just the tradeoff here between encapsulation vs C-like structs, I guess.
<karlguy>
And I'm on the wrong side of preference
<stratact>
I'm fine with Zig having pub fields by default, just allow Zig programmers to specify a "priv" to a field is all I'm suggesting
<andrewrk>
fields are kinda part of the public API whether we like it or not
<andrewrk>
they affect the size of a struct, which may affect the decision of how the struct could be used
<andrewrk>
if you added 1MB to a struct but it was all private fields, that still should probably be a major version bump
<andrewrk>
or if you make it go from @sizeOf(usize) to larger than that
<andrewrk>
there's reflection, too
<karlguy>
IMO everything should just be public. If person 1 writes a Zig library that has private fields, and person 2 really wanted to access those privates, person 2 could do it though hacky pointer manipulation and whatnot. This is not possible in Java and C++.
<karlguy>
A language actively sabotaging programmers from accessing fields they could access anyways seems a bit un-C-like.
<andrewrk>
I do think private by default makes sense for global variable declarations and functions though
<karlguy>
Yes, of course
donlzx has quit [Remote host closed the connection]
<GitHub191>
zig/master 363f4fa Andrew Kelley: self-hosted: generate LLVM IR for simple function
hryx has joined #zig
darithorn has quit [Quit: Leaving]
<hryx>
Hm. I just spent way too long thinking about this public struct field issue. In the end I guess I agree that struct fields might as well all be public. A struct is just a chunk of data, like an array (and you wouldn't try to control the visibility of individual array elements), plus method sugar if you're using Zig or Rust
<hryx>
Maybe structs just aren't a great candidate for API "objects" in the first place. Good documentation will always help, but I'm curious what language-level opportunities there are to encourage good APIs with proper encapsulation while offering access to raw data as needed.
<hryx>
Related silly idea: read-only struct fields
<hryx>
A struct field qualifier that issues a compiler error if assignment is attempted outside the module or file scope. Example: https://hastebin.com/qahiyocaya.zig
<hryx>
As a possible way to provide some API safety & self-documentation without necessitating hiding data representation (via visibility restrictions a la "priv")?
bheads_ has joined #zig
bheads has quit [Read error: Connection reset by peer]
tiehuis has quit [Quit: WeeChat 2.1]
davr0s has joined #zig
Bas_ has joined #zig
Bas_ has quit [Ping timeout: 252 seconds]
_whitelogger has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Bas_ has joined #zig
<Bas_>
I like how python does it.
<Bas_>
At least in the sense that everything is public and if you want to mess things up by touching the stuff you shouldn't be touching it's on you.
<Bas_>
I still think 'pub' is useful for documentation, to communicate that this is the public interface and that you probably shouldn't touch the other things.
<Bas_>
But almost everytime things are encapsulated it just makes me annoyed because it doesn't exactly do what I want and since I can't touch the privates there's no way for me to fix it either, other than writing my own implementation.
davr0s has joined #zig
zolk3ri has joined #zig
<GitHub114>
[zig] BarabasGitHub opened pull request #1240: Allow for all integer types up to 128 bits. (master...issue-#745-allow-any-integer-type) https://git.io/fNYIu
Ichorio has joined #zig
<GitHub56>
[zig] isaachier opened pull request #1241: Add lower and upper functions (master...lower-upper-functions) https://git.io/fNYth
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
xtreak has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
andi3 has joined #zig
kristate has joined #zig
<andi3>
did someone write a dead simple deterministic finite automata using coroutines? I'm thinking about it but have some sort of metal barrier still
donlzx has joined #zig
<kristate>
Test 16/26 safety integer division by zero...
<kristate>
Program expected to exit with code 126 but instead signaled 9
<kristate>
I was away on a business trip and have returned! I pulled the most recent source and ran into this error upon testing:
<kristate>
Test 16/26 safety integer division by zero...
<kristate>
Program expected to exit with code 126 but instead signaled 9
<winksaville>
I'm trying to run a particular test in std/array_list.zig: test "std.ArrayList.swapRemove". I tried "bin/zig build --build-file ../build.zig test -Dtest-filter=std.ArrayList.swapRemove" and I got a bunch of "No tests to run." and then 173 "docgen example code 1/174...OK" but I don't see anything about std.ArrayList.swapRemove
<bodie_>
hryx / andrewrk, has immutable / val by default been considered?
<bodie_>
I personally favor opt-in mutability, but it's not for everyone. That said, I believe even C++ style guides say everything that doesn't need to be mutable should be declared as const, which is obviously backwards.
<bodie_>
If you need to, I guess you could declare your whole type "mut" and "inherit" mutability into all of its members
<very-mediocre>
is const insufficient?
<bodie_>
"everything that doesn't need to be mutable should be const". what's wrong with that sentence....
<very-mediocre>
I'm asking what you mean by "const by default"
<very-mediocre>
We have `const` and `var`
<bodie_>
oh, so you have to pick one. ok
<bodie_>
I don't use Zig, I was just commenting on what hryx was saying about read-only struct fields
<very-mediocre>
ah I see
<very-mediocre>
unlike languages like javascript, a const pointer to an array doesn't let you write to its contents
<bodie_>
a "read-only" field sounds to me like a val :)
<very-mediocre>
oh you mean for struct properties, i see
<bodie_>
but I guess it's not, since it could have internal mutability
<very-mediocre>
yeah currently it's not granular, if you have a const reference to a struct you can't modify any of its properties of that struct through that reference
<very-mediocre>
it's unclear what would happen if const/var were implemented per-property, then I guess there'd be some precedence rule
<bodie_>
I should probably be more familiar with Zig syntax before commenting on it :D
andi3 has quit [Quit: Page closed]
<very-mediocre>
I'd say if you had a var pointer/alias to a struct, and a const struct property, then the property should stay const
<very-mediocre>
(hypothetically)
<bodie_>
That's how it would work in other languages
<very-mediocre>
bodie_: I theorycraft a bit too, I haven't used zig enough, really busy with work and managing autoimmune disease latelly :(
<very-mediocre>
so I say a lot of silly things :)
<very-mediocre>
also i'm holding back from using it a bit until I play around and find a paradigm for certain things
<very-mediocre>
for example, simple Lz77 encoding... Implement as a stream or generator?
<very-mediocre>
Just stuff like that. For now going with a stream... But I'm not too committed.
<bodie_>
I have a couple of projects on the back burner I'm thinking of using Zig for, but they haven't taken priority yet.... :/
<bodie_>
There are still a few things missing, and I guess I could always use C libs, but for most stuff for me, for now, it's just simpler to use Go.
<bodie_>
That said, it's really fun to watch the progress, and the free coroutines are really intriguing.
<very-mediocre>
Another thing: consts that are declared outside of structs are implicitly comptime
<very-mediocre>
really great for pre-generating static data
<very-mediocre>
but there's no caching
<very-mediocre>
say you're doing a performant HashMap and you want it to expand to a prime number capacity
<very-mediocre>
would be great to pre-generate primes at comptime but currently it kills the compile time, so you're better off copypasting a large sequence of them instead
<very-mediocre>
and I've read on github "everything" might become a struct in order to simplify the language
<bodie_>
that's the kind of thing where a filesystem memo macro could be cool
<very-mediocre>
iirc there's an "embed" thing but I've yet to try it
<very-mediocre>
if everything becomes a struct, I'm a bit unclear if consts declared in a struct body would be implicitly comptime too
<very-mediocre>
don't think you can bitcast a whole array
<bodie_>
isn't the []u8 from embedFile a var?
<bodie_>
I dunno why not
<very-mediocre>
yeah but it'll contain all the values
<very-mediocre>
hmm, maybe if bitCast could return a []u32 for example
<bodie_>
Maybe you could bitcast []u8 to []u32 :D
<very-mediocre>
otherwise I'd go with bytesToSlice to get an array with the bytes combined into elements
<bodie_>
I guess slice wouldn't work because it has a byte representation such as size, start, end or whatever
<bodie_>
I could go find out, but then again I could go work on the stuff at the top of my pile so I could get to the stuff I should actually be considering Zig for :/
<very-mediocre>
lol
* bodie_
vanishes in a puff of smoke
<very-mediocre>
I'm pretty sure it'd be byteToSliec
<very-mediocre>
embedFile gets you an array/slice of bytes, you'd need to combine each 4 into 1 var
<very-mediocre>
to get u32
<bodie_>
yeah but why can't you just cast []u8 to []u32
<very-mediocre>
if that works, sure
<very-mediocre>
no idea if it does
kristate has quit [Ping timeout: 240 seconds]
<Bas_>
byteToSlice can covert your []u8 to an []u32
kristate has joined #zig
Ichorio has quit [Read error: Connection reset by peer]
donlzx has quit [Quit: Leaving]
davr0s has joined #zig
kristate has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
isd has joined #zig
<Bas_>
How do I access a struct inside a struct? Like the hashmap in std has a _pub const Entry = struct { ... }_
<Bas_>
Oh it works when I do HashMap(...).Entry, but not when I try to access Entry from the variable I get back from the HashMap function.
unique_id has quit [Quit: Konversation terminated!]
very-mediocre has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
<Bas_>
I think there might be something wrong with alignments of structs. It seems to take the alignment of the first field instead of the one with the largest alignment.
mahmudov has quit [Ping timeout: 240 seconds]
Ichorio has joined #zig
very-mediocre has joined #zig
<very-mediocre>
>"How do I access a struct inside a struct?"
<very-mediocre>
from within a struct method, the 1st param will be the struct instance
<very-mediocre>
otherwise if you do `const instance = MyStruct.init()` you should be able to do `instance.Entries`
<very-mediocre>
oh, you mean a struct definition inside a struct definition, my mistake
<very-mediocre>
you're right, that's a limitation of using functions that return structs, the namespacing becomes annoying
<very-mediocre>
what you can do is use a separate variable to return the struct type, e.g. `const HashMap_t = HashMap(...)`
<very-mediocre>
then `const a_hash_map = HashMap_t.init(); const EntryType = HashMap_t.Entry;`
<very-mediocre>
annnd it's later than i thought, i'm out :/
very-mediocre has quit [Quit: Page closed]
hryx has quit [Quit: Page closed]
<Bas_>
Ehm... so does the init() return another type than the HashMap(...) ?
<Bas_>
I thought they were the same.
kristate has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
andi3 has joined #zig
<andi3>
its curious how zig prioritizes reading over writing and yet here we are reading two hours allocator function pointer indirections trying to figure things out or squinting at some obscure init functions just because there is no proper ctor dtor and things are hacked together in some way
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Read error: Connection reset by peer]
kristate_ has joined #zig
isd has quit [Quit: Leaving.]
mahmudov has joined #zig
dbandstra has joined #zig
Ichorio has quit [Ping timeout: 244 seconds]
kristate_ has quit [Ping timeout: 264 seconds]
Bas_ has quit [Ping timeout: 252 seconds]
daritestbot has joined #zig
v1zix has joined #zig
daritestbot has quit [Remote host closed the connection]
andi3 has quit [Quit: Page closed]
_whitelogger has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]