ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<Ronja>
Hejsil: does the standard library (plan to) support things like "get character count" for say utf-8 encoded strings? or methods like to_upper() for non-ascii characters?
<Hejsil>
Idk
<jreut>
:) glad to hear it. it's been great having a builtin test facility in a systems language
davr0s has joined #zig
<Ronja>
I'm tempted to comment that not seemlessly supporting unicode strings in a brand new language quite unappealing for very large swaths of the world in 2018
<Ronja>
I'm talking about things like slicing, truncating, to_uppering etc. of strings internally encoded in utf-8, preferrably
<bheads>
Thats really a std lib problem
<bheads>
They put auto decoding for utf-8 in D, and now they are trying to remove it
<euantor>
All of the above can be easily implemented in the standard library - either by wrapping a C lib or by writing it fresh
<euantor>
Remmeber that Zig isn't 1.0 and something not being in the standard library yet doesn't mean that it'll never be
<Ronja>
yes I am aware
<euantor>
I would imagine the only reasons for it not already being there are: nobody has needed it enough to spend the time; it's fairly boring work
<bheads>
The language is still in flux, so there is no point in polishing the stdlib yet. Things are added as people need it.
<Ronja>
but can something like const str = "åäö"; const slice = str[1..2]; assert(mem.eql(u8, slice, "äö")); really be a std lib thing? I've never written a programming language, though, so...
<bheads>
You need a function to decode that string
<Ronja>
why?
<bheads>
having the language do it would hide the implmentation
<bheads>
utf decoding is not cheap
<Ronja>
you say that like it's a bad thing
<bheads>
not saying that
<bheads>
Zig is avoiding "magic" code
<Ronja>
I get that
<bheads>
besides what if my array is just bytes
<Hejsil>
If you decode your "åäö" into a []u32, then your slicing would work
<bheads>
I dont want that to get decoded
<Ronja>
I guess really my point is that "strings == byte arrays" is an easy thing to do but it makes the language very very inconvenient for many many people
<bheads>
no strings != bytes
<Ronja>
a separate unicode-aware string type that does decoding, character counting, slicing and uppercasing for me is really nice
<bheads>
sure, that can be in user land
<bheads>
you dont need that in that language
<Hejsil>
It's probably best if it isn't
<Hejsil>
At least in Zig
<bheads>
They added it in D, and its a mess
<Ronja>
I guess, but can the user land implementation be as nice as str[n..m] or will become something like utf8_str_slice(strptr, n, m)
<Hejsil>
Ronja, as I said. You could decode into a []u32, and then it would work
<Hejsil>
But it depends on what you need from you string
<bheads>
also in your string slice example what does n and m mean? codepoints or indexs?
<Hejsil>
There is probably gonna be something like an UniString, and then you can call str.slice(n,m)
<Hejsil>
In the context of strings, it's probably codepoints
<bheads>
it should be
<Ronja>
bheads: codepoints. I don't know why I would every want anything else in string contexts.
<Ronja>
ever*
<bheads>
that way mixing arrays and strings are bad
<bheads>
to easy to mix up codepoints and index
<Hejsil>
Well, if you have precomputed indexs that are safe to slice with on a string, then you wouldn't wonna pay the cost of slicing with codepoints
<Ronja>
bheads: that's exactly my point
<bheads>
so slicing syntax would be a bad choice
<Ronja>
what do you mean? python and rust can do slicing on codepoint counts just fine
<bheads>
yeah but now slicing means two different things
<Ronja>
I guess, technically
<Hejsil>
Well, if your string is UTF8 encoded, then your slicing operation ins O(N)
<Ronja>
yse
<bheads>
no its not
<bheads>
you need to decode to find the index bounds
<euantor>
Zig's string is more like Rust's CString
<Hejsil>
Enligten me
<Hejsil>
And how is that not O(N)?
<bheads>
I read it as O(1) my bad
<Hejsil>
euantor, ye that's about right
<bheads>
zig doesn't have strings, just arrays
<bheads>
strings have data and an encoding
<bheads>
we are just hardcoding in the encoding, normally utf-8
Hejsil has quit [Quit: Page closed]
Zaab1t has joined #zig
<oats>
Is an aim of Zig to replace C for use in microprocessors and embedded platforms, too?
<benjikun>
I think the potential to maintain that possibility is an aim
<benjikun>
anyone can correct me if I'm wrong on that
<DutchGh0st>
In rust I have a function that returns an _mm128i struct, which is a simd struct...
<DutchGh0st>
I import that into zig, but set the return type to a 'c_int'
<DutchGh0st>
I then call the function, cast the reference to a Zig struct that has an array of 16 bytes internally to match the size..., is it safe to then derefence it?
<DutchGh0st>
*call the function, take a reference to the return value, and cast it
Zaab1t has quit [Quit: bye bye friends]
Zaab1t has joined #zig
<MajorLag>
oddly enough, there doesn't seem to be a way to declare a struct, or a struct field, with an alignment. Best I can come up with is having an init fn that has an aligned return: `pub fn init() align(16) T`
<DutchGh0st>
I have not had a *correct* output on just a single standing array
<benjikun>
oats: Well they are criticizing the lack of independent sources on the wikipedia article
<benjikun>
There are only two real "articles" on zig :/
<benjikun>
These wikipedia people are the most passive aggressive people I've ever met
steveno has quit [Quit: Leaving]
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
<MajorLag>
yeah, you can create an instance of a struct with an alignment, but can't create the type with an inherent alignment.
<MajorLag>
er... or maybe you can and I just had the syntax wrong despite several variations
<benjikun>
Is stdlib documentation planned for anytime soon?
<MajorLag>
I don't believe so
<benjikun>
dang
<MajorLag>
`const _mm128i align(16) = struct {` has an alignment of 8 in my test, but the compiler didn't bark about it so that's probably a bug.
<MajorLag>
No, wait, I think that means "align this variable (_mm128i) at 16", but since _mm128i is a type, that's effectively meaningless. So there isn't a way to say "this type is aligned to X", at least not that I can fidn.
<DutchGh0st>
well, there should I think?
<DutchGh0st>
In rust we have `#[repr(align(N))]`, where N is the alignment
<DutchGh0st>
but maybe I just have to wait untill simd stuff comes into Zig :)
<DutchGh0st>
it was just a test if it was possible currently with FFI,...and...it basically is not really
<benjikun>
If I'm doing a "@cInclude("X11/Xlib.h");" and I want to do something like "const display = c.XOpenDisplay(0x0);", how would I do that?
<benjikun>
It's complaining about not being able to implicitly cast to '[*]const u8'
<MajorLag>
in this case probably `const display = c.XOpenDisplay(@intToPtr([*]const u8, 0));`. Ideally it would be `const display = c.XOpenDisplay(null);`, but from the error it looks like zig didn't translate `char *` as nullable.
<benjikun>
oh okay, I see tysm
<benjikun>
well, actually using 'null' lets it compile now
<MajorLag>
maybe it did correctly translate it and the error only reported the non-nullable portion of the type.
<benjikun>
hm
<benjikun>
Xlib uses a #define for Mod1Mask and some other stuff (`#define AllMods (ShiftMask|LockMask|ControlMask| \`)