<fengb>
Yes, but it doesn't seem like Zig can translate to or from bitflags yet
<fengb>
I took a look at translating and there's oodles of underspecced edge cases
<tgschultz>
huh. Well, deserialize can do it.
<tgschultz>
but it would be making a copy.
<fengb>
Yeah, I just need to hide the definitions
<fengb>
So C can deal with it, and Zig can separately deal with it. Until I gut the C code anyway
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
<curtisf>
What does the error `control flow attempts to use compile-time variable at runtime` indicate? It's singling out the `<` in `if (list.count() < field.min_take_count) {` where the rhs is a comptime `usize` inside a `inline for` loop
<andrewrk>
curtisf, it means you have a runtime branch and in one or more of the branches you load or store to a comptime variable
<andrewrk>
since the compiler doesn't know if the branch will be taken, the variable's value cannot be determined
<curtisf>
hmm how should I be writing this? There's other branches in this inline loop that need to be resolved at comptime but this one I want to be done at runtime
<curtisf>
I think what I want is for this comptime expression to be treated as an integer literal (so e.g. it's the same as `if (list.count() < 4)`). Is there a way to do that?
ltriant has joined #zig
qazo has quit [Read error: Connection reset by peer]
<curtisf>
hmmm extracting it into a `var` out of the condition fixed it... I'm confused
<curtisf>
andrewrk: would you be able to explain why `var c = list.count() < field.min_take_count; if (c) {......` is OK but `if (list.count() < field.min_take_count) ......` is rejected?
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
<andrewrk>
probably a bug
<curtisf>
do you think the right thing is that they are both rejected or both accepted?
<andrewrk>
I'd need to see a more complete example
<andrewrk>
but I'm about to go to bed
<curtisf>
Ok, I'll try to reduce it later
<andrewrk>
thanks. those reductions are very helpful
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
fengb has quit [Ping timeout: 260 seconds]
qazo has joined #zig
darithorn has quit [Remote host closed the connection]
mikdusan has quit [Quit: WeeChat 2.3]
mikdusan has joined #zig
qazo has quit [Read error: Connection reset by peer]
curtisf has quit [Ping timeout: 260 seconds]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
ltriant has quit [Quit: leaving]
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
brakmic has joined #zig
mingyangyin has joined #zig
<mingyangyin>
hi, what is the function of parsergen in the Zig code base?
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
mingyangyin has quit [Remote host closed the connection]
qazo has joined #zig
mingyangyin has joined #zig
mingyangyin has quit [Remote host closed the connection]
samtebbs has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
<tiehuis>
you can still do it manually now, since APInt does seem to support approriate functions for getting specific words
<tiehuis>
its just a bit of work and the limb sizes only match on 64-bit etc so there are some edge cases to consider
tiehuis has quit [Client Quit]
squiddlebit has joined #zig
hio has joined #zig
bheads has joined #zig
qazo has quit [Read error: Connection reset by peer]
<gonz_>
andrewrk: Given zig's focus on readability over writability, do you think there might be a reason in the future to do an overhaul of needless abbreviation in the standard library? Things like "buf" are pointless, usually.
<Tetralux>
So long as we don't become Java, sure.
<Tetralux>
Because then I'd hate you. With the passion of a thousand blue suns.
<Tetralux>
And that would not be good xD
<gonz_>
andrewrk: I'm not just asking for the bike shedding factor, by the way. I code mainly by voice and when a language has a culture of abbreviating everything, i.e. C it becomes much harder to actually write it. I would argue the savings are pretty small for everyone else also.
<Tetralux>
Does "code by voice" mean you say it out loud - or out loud in your head? Only, 'Buf' (buff) is a bad example of that isn't it? :)
qazo has joined #zig
<gonz_>
Tetralux: I use dictation software and plug-in infrastructure for that software to code, I don't touch the keyboard (I do this with a microphone, obviously). Everything I've written in this channel has been dictated.
qazo has quit [Read error: Connection reset by peer]
<gonz_>
`buf` is a problem, as are things like `msg`.
<gonz_>
In general, everything that's not a natural word is going to provide issues.
<gonz_>
`msgBuf` == "Made sun gust ship bat urge fine"
<BitPuffin>
shouldn't std.ArrayList have some way to get a ptr to an element in it other than converting to a slice and indexing it and taking its address?
fengb has joined #zig
qazo has quit [Read error: Connection reset by peer]
<Tetralux>
BitPuffin: l.ptr() + n
<Tetralux>
gonz_: Oh cool.
<Tetralux>
gonz_: That does make sense.
<BitPuffin>
I meant more as a standard part of the interface Tetralux
<BitPuffin>
so you could do list.ptrAt(i)
<BitPuffin>
or something like that
<Tetralux>
There should prob be smartness in there where "message buff" searches for symbols, finds msgBuf and then completes that. :3
<Tetralux>
BitPuffin: I gotcha.
<Tetralux>
gonz_: But yeah - I can see how that could be painful.
<gonz_>
"Smartness" rarely works. I basically just speak vim.
<gonz_>
`ptr` is another classic.
<gonz_>
`p` really is no worse than `ptr` if you want short names. But short names are really only good in the short term, they're not for production code and other long-lived things.
<gonz_>
Local names obviously can be very short, but in those cases `p` is probably what you want to use anyway.
squiddlebit has quit [Quit: WeeChat 1.9.1]
<gonz_>
In general I think the attachment people have to unnatural abbreviations is usually a historical accident.
<gonz_>
I'm sure someone will manage to be offended by the suggestion that it's needless.
laaron has quit [Remote host closed the connection]
qazo has joined #zig
laaron has joined #zig
qazo has quit [Read error: Connection reset by peer]
<Tetralux>
gonz_: You'd probably like Jonathon Blow's code then. He doesn't abbreviate much :D
<fengb>
I wish Jai was public. It looks quite awesome from the vague video snippets
<fengb>
Random question: did Go invent the term "slice" for fat array pointer?
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
<mmx87>
><gonz_> `p` really is no worse than `ptr` if you want short names. But short names are really only good in the short term, they're not for production code and other long-lived things.
<mmx87>
It is, p could also stand for something else, while most people are aware what ptr should mean. I think you're currently arguing for your specific use case mostly.
<gonz_>
Given the premise that short names are local, it's not very likely to be many other things. Probably you're not doing yourself any favors by having other things in scope that could be `p` anyway.
<gonz_>
Also, I would argue that writing `pointer` is not very hard, certainly not much harder than `ptr`.
<fengb>
`p` is harder to scan since it's vaguely similar to `i` and `j`
<fengb>
I like `p` as a prefix, but standalone it looks weird
<gonz_>
You're not trying to save hard drive space or anything like that. There's no upside to having a long-lived API that uses, for example, `ptr`.
<mmx87>
gonz_, have you considered the line length? If we would spell out anything than that would make lines very long, like in Java.
<gonz_>
`ptrAt` is a pretty horrible choice. `pointerAt` would've obviously better.
<gonz_>
Boo-hoo, my lines are so long…
<gonz_>
Really?
qazo has joined #zig
<fengb>
... I don't see anything wrong with ptrAt
<gonz_>
Saving 4 letters, for what?
<mmx87>
Yeah, really. Not only one function, but other functions also. You need to see it as a whole if you spell out anything then it usually makes the lines very long.
<mmx87>
Let's say you write a DNS server? Would you spell out DomainNameSystem? OK, that might be different because it's different from shortening a word, but it still would be annoying for your with voice software.
<fengb>
`standard.input_output.printFormatted`
<gonz_>
I think people are little bit too attached to some of these things. No, common abbreviations are not difficult: DNS, API, HTML, HTTP…
<gonz_>
Don't presume to know what's difficult or not.
<gonz_>
Get some perspective as well, maybe the way the people have been writing C is not actually the best way to formulate things.
<samtebbs>
"be excellent to each other"
<gonz_>
There was at one point a reason to use short names and odd abbreviations, but that's not really relevant anymore. Invoking Java as an argument for these things is pretty garbage.
<companion_cube>
short names can be easier to read, too
<mmx87>
No, it's a fair argument. Because everything is often spelled out. Why do you think Java as an example is invalid? I know Java is overly verbose where it doesn't need to, but still all lines would be longer, which can sometimes be painful if you need to have multiple windows of code open.
<companion_cube>
(it's not just in C culture, also in functional languages, btw)
<gonz_>
I'm not going to disagree that it's everywhere, but particularly unnatural abbreviations are more common in certain languages. The way certain people defend them is certainly tied to historical C-isms.
<mmx87>
I don't think there's any argument that would convince you that they might not be as bad as you make them out to be. You're arguing from the standpoint that these short names are inherently flawed.
<gonz_>
In most contexts, yes.
<gonz_>
I think they're vastly overused for the savings that they do actually provide in terms of big picture.
<gonz_>
I think they're an objectively bad choice in terms of public, long-lived API.
<BitPuffin>
I said ptrAt because we already have .ptr on slices ¯_(ツ)_/¯
<gonz_>
More than anything I think the argument for them is usually based entirely on historical accidents and familiarity. The argument in functional languages that provide enough abstraction where you can't actually name something something specific is precisely that. This usually does not apply to lower-level languages.
halosghost has joined #zig
Ichorio has joined #zig
<gonz_>
With that said I'll try to be less and agonistic about this, because obviously I have a completely different viewpoint than most people here.
<gonz_>
*antagonistic
brakmic has quit [Remote host closed the connection]
<samtebbs>
In the end you can't please everyone. It seems that most people are fine with short names and that, combined with the typing ease and line length savings, makes them fine.
<samtebbs>
For everything in existence there's going to be a group of people (however big or small) that oppose it, but the important thing is to go with the preference of the majority.
<halosghost>
not to prolongue this conversation that I just walked into, but I would suggest that going with the majority isn't always the right call
<halosghost>
for the particular subject matter, I can't speak to it as I missed out on the conversation
mikdusan1 has joined #zig
mikdusan has quit [Ping timeout: 248 seconds]
<BitPuffin>
I mean on a standard library or language level I think it doesn't hurt to work towards being accomodating towards people who might for whatever reason be excluded or inhibited by a design decision because of disabilites or what not.
<gonz_>
I think it might be immaterial in the long run, since you're always going to be dealing with C and all of that. I don't think that there is a good reason for new language to actually inherit these things.
<halosghost>
mmx87: thanks
<gonz_>
But now I regret even bringing it up anyway
<halosghost>
a bit slow to load, that page :)
<BitPuffin>
that said if an abbreviation is common enough it could be the case that the right place to address this problem is in the dictation software. but I don't know enough about how hard it is to make them recognize a codeword or whatever for ptr ("putter"?)
<gonz_>
BitPuffin: Many things are possible here: you could add an abbreviation command that allows you to say "abbreviate [word]" and have those set up. I would destress the importance of the dictation software, perhaps, and instead emphasized that maybe some of this is actually not needed anyway.
avoidr has joined #zig
<gonz_>
Anyway, I'm not going to comment more on it because I doubt that this would actually be something that can be changed for this generation.
<BitPuffin>
okay so if we set aside the dictation problems
<BitPuffin>
I agree that it's not strictly needed to say ptr instead of pointer
<BitPuffin>
but I pretty much pick which one seems better even if it's just a tiny amount
<BitPuffin>
ptr is also one of those that often glues itself onto some other longer word
Akuli has joined #zig
wootehfoot has joined #zig
mikdusan2 has joined #zig
mikdusan1 has quit [Ping timeout: 268 seconds]
darithorn has joined #zig
<andrewrk>
I do think that once zig has better IDE integration, it will make sense for names of things to be longer in general
<andrewrk>
IDE integration should in theory help a lot with voice commands because it limits the set of things you could possibly want to type, thus making it easier (and more discrete) what the programmer wants to input
<gonz_>
IDE integration does help, yes, but to be honest I think that one helps equally with the odd abbreviations.
<gonz_>
What I mean is I think that one is an equally strong argument for three letter abbreviations that only save a few characters.
<andrewrk>
I agree with you that more explicit names are in general preferable. I see IDE integration as a way that abbrevations matter less because of auto completion, thus enabling longer and better names
<fengb>
Is there a clean way of shutting off tagged union checks? In my critical path I want to just use the raw value directly, but I want to be able to switch on a tag
qazo has quit [Read error: Connection reset by peer]
<fengb>
Oh it just works. I thought I needed a packed union as well but I didn't
porky11 has joined #zig
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
SimonNa has quit [Remote host closed the connection]
curtisf has joined #zig
darithorn has quit [Quit: Leaving]
<andrewrk>
fengb, those accesses are safety-checked too, so if you access the wrong field in a safe build mode you'll get a panic
<andrewrk>
you can disable all safety checks in a given block with @setRuntimeSafety
qazo has joined #zig
<fengb>
Yep I see it. That's actually really helpful since I *should* know which ones are active but this will crash instead of corrupting memory
qazo has quit [Read error: Connection reset by peer]
<zxrf>
gonz_: what do you think of short variable names like "i" in short loops? i guess that's the only place they might seem appropriate
<fengb>
For some reason I had assumed the compiler would be more anal and force me to check
<andrewrk>
fengb, that's been proposed but I resisted it
<scientes>
zxrf, you just can't resuse them
<scientes>
in the same scope
<gonz_>
The smaller the scope, the more appropriate short names are, in my opinion. I think most people agree, though.
curtisf has quit [Ping timeout: 260 seconds]
<gonz_>
Something that is globally available isn't something that I would want to have a short name and/or have too many abbreviations and it.
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
<zxrf>
gonz_: that makes sense. your perspective on this was very enlightening for some reason, thank you
qazo has joined #zig
<gonz_>
I would add that how generic something is also makes a difference: `mapM f m` is simultaneously good and bad; `mapM` is globally available (if imported) so should probably be `mapMonad` but `f` is fine to use here because it's a completely generic function over all monads, etc.
<gonz_>
(and `f` & `m` are also locally scoped)
<zie>
are there docs for the standard library somewhere?
<hryx>
zie: not yet but planned for next release. for now your best bet is to look through the sources in std/
<zie>
hryx that's what I started doing :)
qazo has quit [Read error: Connection reset by peer]
qazo has joined #zig
qazo has quit [Read error: Connection reset by peer]
fengb has quit [Remote host closed the connection]
Ichorio has quit [Ping timeout: 252 seconds]
mawaldne has joined #zig
laaron has quit [Remote host closed the connection]
qazo has quit [Read error: Connection reset by peer]
<andrewrk>
scientes, interesting, that error that gcc 9 points out, is precisely defeating the safety I tried to introduce
<andrewrk>
fine, I won't use c++ features, they only seem to cause problems
<scientes>
that's how i feel about C++
<Tetralux>
People still use C++ features? xD
<andrewrk>
all I did was delete the copy construction and assignment operator so you couldn't accidentally use ConstExprValue wrong
<Tetralux>
Yeah - I tried compiling the branch earlier and ran into that.
<Tetralux>
By "use it wrong", what do you mean?
<Tetralux>
.. that you shouldn't copy one that's already been set up by the system?
<Tetralux>
.. or indeed, accidentally by using '='?
<andrewrk>
right
<Tetralux>
Is that because data is stored by value within the struct, and this value is the only one that should exist for a particular thing?
<Tetralux>
Something like that?
<andrewrk>
wow, I just discovered that you can jump to another line in gdb
<andrewrk>
that's useful
<scientes>
the main problem i have with C++ is that there is this huge learning curve
<scientes>
and I can't rationalize it
<scientes>
because C++ seems full of strange edge cases and bugs
<Tetralux>
Oh absolutely.
<scientes>
like when you use operator overloading you don't get the same operator precedence rules
<scientes>
which is super weird
<Tetralux>
If I ever program in C++
<scientes>
and makes me distrust the whole language
<Tetralux>
I only thing I use is fn overloading and auto.
<Tetralux>
If I can at all avoid it.
<scientes>
zig has auto
<Tetralux>
This is a good thing.
<scientes>
like I was writing a patch for llvm because i thought something was a linked list, and the llvm documentation said it was a linked list
<scientes>
and then i realized it was just an array
<scientes>
fuck me
<Tetralux>
Although, I must say, having to state the type can be handy instead of having to look it up.
<scientes>
and even Chris, the author of LLVM, said my idea was a good idea.....
<scientes>
if the author can't keep track of the data structures.....
<Tetralux>
How the hell does a linked list and an array become so hard to tell which one is being used? xD
<scientes>
well all the APIs for operands in LLVM use it like a linked list
<scientes>
but its a damn array
<daurnimator>
gonz_: how do you about slices having .ptr and .len. I don't think I'd want them to be any longer (.pointer and .length) as they are so common to use as part of a call: `if (someFunction(a.ptr, b.ptr) < a.len) .....`
<daurnimator>
gonz_: likewise zig uses 'fn' instead of 'function'
<scientes>
that comes from go
<scientes>
which initially has it "function"
<scientes>
or well, its pretty simple
<Tetralux>
Oh yeah - meant to say this earlier - but if I had to dictate what I was writing, I'd REQUIRE the ability to set up abbreviations.
<scientes>
fn is great
<scientes>
Tetralux, no, macros are not a good idea
<scientes>
but you have full control over your namespace
<daurnimator>
scientes: ehhh; coming from lua I don't mind writing out 'function'
<scientes>
I think what zig has now (that the namespace type was removed) is beautiful
<Tetralux>
I like that each file is it's own namespace.
<andrewrk>
the main reason for `fn` being short is that it's a keyword in function types
<daurnimator>
the main time it gets annoying is inline closures: `sort(t, function(x,y) return x < y end)`
<andrewrk>
nice we said the same thing
porky11 has quit [Ping timeout: 252 seconds]
<Tetralux>
But it is quite irritating how you can't tell what namespace the code inside a file belongs to without tracing it from top-down.
porky11 has joined #zig
<scientes>
but a static analyzer could do that
<scientes>
i think the way it is done is good
<Tetralux>
Indeed - but I don't believe I should need one to know xD
<scientes>
agreed
<Tetralux>
Well - I don't "need" one _now_
<scientes>
that's why in the std lib we always use them under their given name
<Tetralux>
I can go through the files and figure it out
<Tetralux>
But you get my point
<daurnimator>
'fn' is a good short choice because 'fn' doesn't tend to appear as a sequence in any english words
<scientes>
because it needs a vowel
<scientes>
maybe finnish
<daurnimator>
which means that greping for 'fn' is 99.9% of the time only going to return function definitions
<Tetralux>
daurnimator: That _is_ handy.
<gonz_>
I have plenty of voice macros set up specifically for zig (I say "all your base are belong to us" and it's activated). That's not so much the issue as promoting an ecosystem where these kind of things are everywhere. You can't set up macros for every tiny thing. I have macros for the base syntax of zig and that's pretty much it.
<scientes>
gonz_, i agree that a static analyzer should not be required, i do 99% with git grep (which is faster than grep)
<scientes>
and find | grep
* daurnimator
mainly uses 'ag' (the silver searcher)
<Tetralux>
Personally, if I needed to dictate, I'd want to just teach it how to recognise and activate things. Like, if I open a zig file, know that I wanna enable the zig macros.
<gonz_>
I also have voice macros that apply to many languages, but have specific implementations in each language, like saying "exported function" which in zig outputs "pub fn ..."
<Tetralux>
AND
<Tetralux>
I would NOT want to set them up manually.
<daurnimator>
gonz_: not 'export fn'... ?
<hryx>
tiehuis: Thanks for addressing my big.Int question, I didn't see that. I'll give it a shot tonight
<daurnimator>
gonz_: shouldn't `pub fn` be "public function"?
triplefox has joined #zig
<gonz_>
I suppose it should be, yes. The point is that they're a known set of things that each language does differently.
<Tetralux>
This is true.
<Tetralux>
Like - maybe I'd type out some code, or open a code example
<Tetralux>
And be able to easily teach it - "Hey - this is what an if-statement looks like - make that a macro."
<Tetralux>
I wouldn't probably do it by saying that.
<gonz_>
Tetralux: I think you should probably try this before you have set opinions on it. It's extreme hard to set something up that is robust and the more complex you make it the less stable it's going to be.
<Tetralux>
Oh - I have tried to use dictation before.
<Tetralux>
I wanted to strangle it pretty quickly.
<Tetralux>
I'm more thinking out loud. x)
<Tetralux>
I _want_ things to be amazing.
<Tetralux>
And it won't ever be if someone doesn't imagine it being.
<Tetralux>
Long way of saying, "aim high."
<scientes>
I couldn't imagine doing that
<triplefox>
happened to see this discussion and i could weigh in with some of my notes on symbol length when i tested using lengths of two, three, and four characters for everything...
<scientes>
it would be like talking to a very dumb child
<triplefox>
at two, you get a lot of collisions. at three you don't, but you can't read the full word most of the time. four or more you usually can
<gonz_>
scientes: It's actually surprisingly easy and pretty precise. It helps if you can just speak vim.
<scientes>
but you still have to be precise
<scientes>
and I just don't work that way
qazo has joined #zig
<gonz_>
daurnimator: That's the one people usually see and they it's the one I saw before I started doing this.
<Tetralux>
gonz_: Also, I don't have _set_ opinions on it. Just want it to be good, and thinking of ideas of how one might approach it. I'd want to be _able_ to set it up myself, but it could probably be better. I'm not sure how, but it probably could be. :)
<gonz_>
scientes: Well, I didn't want to do this. I woke up one day and my hands hurt basically immediately when I started typing.
<Tetralux>
If anything I just said came off badly, I apologise - wasn't meant as such.
<daurnimator>
gonz_: I had that too once. I took a week long break from typing and swapped to using an ergodox at work: I have been okay since.... as long as I don't use a normal keyboard for long
qazo has quit [Read error: Connection reset by peer]
<oats>
I love my ergodox
<oats>
Been on the lookout for a nice compact ergonomic keyboard I can use on the go
<gonz_>
No offense taken or perceived.
<gonz_>
Even though I never wanted to start doing it I can actually say that it's not the blocker that I thought it would be and I probably will continue doing it pretty much forever. Once you get really into a language you set up the basics and you're pretty much up and running with some reasonable level of efficacy.
letoram has quit [Ping timeout: 258 seconds]
edr has quit [Ping timeout: 258 seconds]
hryx has quit [Ping timeout: 258 seconds]
<gonz_>
daurnimator: With regards to ptr and len I'm not really sure. They're not your usual identifiers and like you said they show up a lot. Doing the same thing with things that show up drastically less isn't the same to me. I should probably just bite the bullet and set up "pointer" to automatically output "ptr".
<oats>
I like the look of the Atreus, but I worry it has too few keys
<oats>
The Planck is super cool, but it's backlogged and not as ergonomic
<gonz_>
Yeah, I also have ErgoDox (EZ)
<daurnimator>
oats: I think the key thing for me was reducing use of my pinky and "scrunched" movements: having ctrl and windows key on the thumb is the main benefit
<oats>
Yeah, extra thumb keys are great
edr has joined #zig
<daurnimator>
also that I can pick my own "width"
<daurnimator>
A planck doesn't do either of those things: I don't consider it an ergonomic keyboard at al
brakmic has joined #zig
<oats>
I think a split Planck would be pretty ideal for me, but that's a bigger project
<companion_cube>
(it kind of blew my mind that people say JS is basically a functional language, when it's so not expression oriented)
<daurnimator>
companion_cube: I like that 'return' always means "return from current function". so if I want 'return' to work in a block.... you need a function :)
<companion_cube>
I'd rather not have return at all, except for functions, yeah
<companion_cube>
the break syntax is useful in 1% of the cases where you want a block to return an expression, and have shortcut cases in the middle; otherwise it's a lot of overhda
<companion_cube>
overhead
<companion_cube>
I think I'd just like zig's syntax to be a bit closer to rust's…
<daurnimator>
companion_cube: modern rust often looks like line noise to me. I prefer far fewer symbols and more keywords
<companion_cube>
I don't think rust has more symbols than Zig
<companion_cube>
but anyway I'm thinking of the expression syntax for blocks, and the if/while mandatory braces
<Tetralux>
I don't like mandatory braces.
<Tetralux>
I like single if guard ifs :p
<Tetralux>
single-line
<daurnimator>
andrewrk: oh that reminds me. did you see my request the other day about a 'do while'?
<companion_cube>
if's just `goto fail` waiting to happen, and you have to wrap the test in ()
<companion_cube>
so it's not even longer to have `if a { … }` instead of `if (a) …`
<companion_cube>
and it's easier to go from `if a {b} else {c}` to `if a {print; b} else {c}` when the if returns an expression
<companion_cube>
returns a value*
<companion_cube>
(I use daily a language with non mandatory braces and it's the worst part of the syntax)
<Tetralux>
I mean, Jai parses all it's files in a 100,000 line game in about 25ms.
<Tetralux>
IIRC.
<Tetralux>
So that logic seems flawed. 'Less I be missing sometihng.
<companion_cube>
maybe jai has a simple syntax then?
<andrewrk>
jai is vaporware
<fengb>
Just like V? :P
<mmx87>
I really dislike the generics syntax.
<companion_cube>
(and I do mean that even a pretty naive rust parser using yacc or similar generators, would be reasonably fast without needing tons of optimizations)
qazo has joined #zig
<Tetralux>
mmx87: I love the generic syntax xD
<mmx87>
Functions that return types like in Zig is one step in the right direction.
<companion_cube>
andrewrk: the talk is great, but you're a bit dismissive of academia :/
<mmx87>
Now, Zig should just become a bit more uniform.
<mmx87>
Like declaring functions.
<andrewrk>
companion_cube, I'll concede that
<andrewrk>
it's a weakness and a strength
<BitPuffin>
which talk
<mmx87>
It should basically the same as declaring const variables.
<companion_cube>
it's not all great, but there's good stuff to be found about dependent types and staged programming
<Tetralux>
companion_cube: It uses Thing :: Value or Thing: Type = Value; for all it's declarations... and has no parens around conditions and non-mandatory braces around blocks xD
<companion_cube>
eeeeek
<mmx87>
Yeah, I know I saw that already , daurnimator.
<andrewrk>
I'm still considering `let` instead of `const`
<companion_cube>
well then I guess it's an implementation-defined syntax
<Tetralux>
andrewrk: RE Jai being vaporware - true. Though, at least we've seen it run.
<mmx87>
I think one of the strengths of hardcore functional languages is that mostly everything is uniform.
<companion_cube>
`let` would be great
<andrewrk>
sure I mean jai is certainly intruiging, but until the source is available, I have no interest in it
<daurnimator>
andrewrk: `let` in most languages is the mutable form
<BitPuffin>
jai probably won't remain vaporware for long
<fengb>
andrewrk: did we resolve needing to explicitly copy iterated values? Is that just going to be a mild footgun for now?
<andrewrk>
mild footgun for now
<daurnimator>
andrewrk: in javascript: `var` is a new mutable variable of function scope; `let` is a new mutable variable of lexical scope; `const` is a new non-mutable variable of lexical scope.
<companion_cube>
but only because they botched `var` initially, really
<Tetralux>
daurnimator: My brain hurts just trying to understand that.
<andrewrk>
that decision is due to legacy baggage of var
<andrewrk>
rust has `let` as immutable
<mmx87>
I think JS is a good example of how to not design a language, lol.
<andrewrk>
haskell has let
<companion_cube>
ML and OCaml, too
<andrewrk>
js is a notable example but I don't think it's prescriptive
<Tetralux>
Does 'let' obviously imply 'const' beyond assosication with functional languages, and Rust, of all things? xD
<fengb>
'let' is also constant in Swift
<andrewrk>
it's pretty easy to understand, if you do it wrong you get a compile error. it's not going to cause confusion
<companion_cube>
`let` is mostly found in languages inspired from functional langs, so… :D
<Tetralux>
One less char to type I suppose.
<Tetralux>
And I'd find it much easier to type than const.
<mmx87>
I think most functional languages use let, because of how it's usually used in mathematics.
<Tetralux>
Well - "much" is maybe stretching a little there
<Tetralux>
But regardless.
<Tetralux>
Still easier.
<fengb>
I'd get slightly irked coming from JS... but I already have to deal with different `const` semantics
<Tetralux>
I'd prefer let=const than let=immutable.
<Tetralux>
So yes.
<andrewrk>
it's intended to address that many people I have noticed use `var` when they don't need to. this is especially problematic in zig because `const` stuff can be comptime but var stuff cannot
<daurnimator>
I like the zig status quo.
<companion_cube>
D uses `immutable` 😱
<Tetralux>
I universally use var under any circumstance unless it's top-level or specifically wanting to be const.
<daurnimator>
Tetralux: in JS?
<Tetralux>
In Zig xD
<daurnimator>
Tetralux: ah. don't :P
<fengb>
const makes your program run faster
<daurnimator>
in zig you should use `const` unless you need to mutate the variable
<Tetralux>
Which is why I use them for things that like.. constants.
<Tetralux>
But I never use immutable variables.
<companion_cube>
so use `let` for immutable, `let mutable` otherwise, so the easy path is the safe one ;)
<daurnimator>
fengb: in zig? not really. in JS? no it actually makes your program slower :(
<Tetralux>
I'd rather the other way. Because I'd never type 'let' by itself then xD
<Tetralux>
I use constants for things that are constant. Like PI. Obviously. But for stack vars. Nope, always mutable.
<fengb>
We'd do smashingcase for that: `letmutable`
<mmx87>
I think it's a good design choice to make everything immutable by default, like Rust.
<Tetralux>
But I don't esp like using loads of stack vars so it balances a bit.
<daurnimator>
mmx87: function arguments already are
<Tetralux>
The machine is mutable - my variables are mutable - I am mutable. ;)
<daurnimator>
but I wouldn't want mutable creation to be longer in zig unless we get e.g. better iterator support
<companion_cube>
so `var` and `let` would be perfect since they have the same length
<daurnimator>
`letmutatable i = usize(0); while (i < 42) : (i+=1)` is far too ugly
<daurnimator>
companion_cube: I actually think that's a bad thing.
<Tetralux>
I'd honestly rather that the compiler just said "Okay. Do they write this variable again after assigning it? No? Then I'll make it const."
<companion_cube>
going back to value-returning-blocks: shorter syntax means it's easier to initialize `let x = { y; z};` instead of `var x; y; x=z`
<daurnimator>
companion_cube: I like that they are different lengths: it makes it so the difference is obvious when you vertically scan code
<companion_cube>
Tetralux: immutable by default is a safety feature
<companion_cube>
not a helping-the-compiler feature
<mmx87>
let mut i = usize(0); while (i < 42) : (i+=1)
<Tetralux>
I was thinking more of a "helping speed and code size" feature - but yes - people consider it a safety thing too.
<daurnimator>
`var x; let y; var z;` is hard to see that y is different; vs `var x; const y; var z` the different length makes it more obvious
<Tetralux>
I don't like thinking of loads of different names for the same thing after each mutation.
<Tetralux>
I like just saying, var ptr = thing; if (cond) ptr += 1; return ptr;
<Tetralux>
.. trash example, but you get the point.
<companion_cube>
of course var is still useful
<Tetralux>
Very. Hence why I almost always use it.
<companion_cube>
but many times, you only assign once
<mmx87>
One common pattern in Rust is shadowing the variable, at least I saw that multiple times.
qazo has quit [Read error: Connection reset by peer]
<companion_cube>
like in swap: `const tmp = x; x=y; y=tmp`
<companion_cube>
making `tmp` a var means you could change it by mistake
<Tetralux>
mmx87: One of the few pattern I like from it.
<Tetralux>
mmx87: I love the ability to shadow an optional with it.
<companion_cube>
(another influence from ML)
<mmx87>
Yeah, it's pretty nice. Especially if an object can be in multiple states.
<mmx87>
Like a file.
<mmx87>
It can be open, or closed.
<Tetralux>
companion_cube: See - that's an example where I *might* use let instead of var. But I wouldn't default to it. It's just not worth my time.
<mmx87>
It's also integrates well into the rust type system.
avoidr has quit [Quit: leaving]
<companion_cube>
Tetralux: well that's because you have bad habits ;) ;)
<halosghost>
this is kind of apropos of nothing
<companion_cube>
(I'm joking, but the goal of `let` in rust is indeed to make immutable the default)
<Tetralux>
..which I part of why I stopped using Rust :p
<halosghost>
but, the way pony deals with swaps is kind of fascinating; (x = y) returns the value of x before assignment
<halosghost>
meaning that, in pony, swap is just: a = b = a
<companion_cube>
ugh, such magic
<halosghost>
lol
<Tetralux>
companion_cube: Like - right kind of idea; wrong effort. Thinking about what variables I'd make mutable and which I wouldn't would stop me using the language, I suspect.
<Tetralux>
..If it was immut by def that is.
<companion_cube>
that's pretty strong
<Tetralux>
In Rust, I found myself wanting to write "let mut" for EVERY var
<companion_cube>
that's definitely a code smell in rust
<Tetralux>
And then go back and remove the "mut" for the things I didn't change.
<companion_cube>
it means you don't use expressions nearly enough :p
<Tetralux>
Just to avoid having to think about it.
qazo has joined #zig
<Tetralux>
It is quite possible it was due to inexperience, indeed.
qazo has quit [Read error: Connection reset by peer]
<Tetralux>
But Rust is too big-idea for me to really like it.
vexu has joined #zig
<Tetralux>
So, having to learn about intracacies like that... meh.
<companion_cube>
I'd kind of expect good Zig to look similar, except more explicit and without borrow checker?
<Tetralux>
Def without the checker.
<companion_cube>
but still, initialization with expression beat re-assignment imho
<Tetralux>
I'm not sure I can agree on that one. x)
<Tetralux>
Partly because of excess indentation, partly because of 'break blk'.
<mmx87>
Zig's current syntax feels a lot lighter than Rust's.
<companion_cube>
which is why `break blk` irks me so much
<Tetralux>
Partly because if-guards read better to me.
<Tetralux>
And partly because situations where I might use expression to set a var, I'd just have a local fn and call it.
<Tetralux>
..except I cannot do that in Zig.
<Tetralux>
:^)
<companion_cube>
mmx87: if you don't use high level abstractions in rust, the syntax is pretty similar…
<companion_cube>
Tetralux: are you really that used to JS ? :D
<Tetralux>
xD
<fengb>
Most nowadays JS uses const
<Tetralux>
More Odin actually. ;)
<companion_cube>
fengb: except you can't have block expressions 🙄
<mmx87>
Well, you'd almost certainly use high level abstractions in Rust though.
<mmx87>
Something like Result for example.
<companion_cube>
declaring/implementing traits is ugly; the rest is pretty concise
<companion_cube>
ah well. not longer than Zig if you use `x?`
<Tetralux>
Why use a higher-level abstraction when you don't need to *shrug* :p
<mmx87>
The syntax is pretty good still.
<mmx87>
Because they're zero-cost and usually you should use them.
<fengb>
companion_cube: sure you can, (() => ())() :P
<mmx87>
For example things like Result are much better than out pointer parameters.
<companion_cube>
fengb: that's so ugly :/
<Tetralux>
mmx87: I hope that's satire xP
Akuli has quit [Quit: Leaving]
<BitPuffin>
andrewrk: I don't have tests but you could run it and see if it works (just a space invaders clone)
<Tetralux>
I'd rather multiple-return than Result.
<BitPuffin>
lmk if you want
<Tetralux>
The headaches I got dealing with that ***.
<mmx87>
Lol
<mmx87>
There's nothing wrong with Results.
<mmx87>
And in Rust they're pretty ergonomic.
<andrewrk>
BitPuffin: thanks. Link?
<Tetralux>
mmx87: I found the whole unwrapping business flat-out confusing and leading to nothing more than loads of indents.
<companion_cube>
zig's error set is more ergonomic when it comes to merging, though
<Tetralux>
I like Zig's errors much better.
<fengb>
I prefer multiple returns, but I'd much rather result than out pointer
<Tetralux>
But would STILL likes multi-return.
<companion_cube>
Tetralux: `x?` you mean? not too bad when it comes to indentation
<Tetralux>
I don't think they had that when I was trying it.
Ichorio has joined #zig
<andrewrk>
Got it
<companion_cube>
rust has had tuples since forever
<mmx87>
I think the biggest pain is that you need to implement a few traits if you want to use your error type conscisely.
<companion_cube>
yep, that's not optimal
fu5ha has quit [Remote host closed the connection]
<Tetralux>
companion_cube: It's possible I just got bogged down looking at the docs, trying to figure out how best I'd architect getting rid of all the optionals / results and getting to the things I wanted xD
<companion_cube>
you could just use `match`…
<Tetralux>
INDENTS.
<companion_cube>
I mean, optionals are results are there for a reason
<companion_cube>
does your screen have 16 columns?
<BitPuffin>
I guess there is a minor thing with tests in puffy/src/capped_array_list.zig
<Tetralux>
Maybe Zig just makes it more obvious that an error is handled differently, whereas in Zig, Result is just a struct.
<Tetralux>
If you see what I mean.
<companion_cube>
an enum*
<Tetralux>
That's worse xD
<companion_cube>
well no, it must be an enum since there are two distinct cases
<mmx87>
Yeah
<Tetralux>
Indeed.
<mikdusan2>
andrewrk: i guess we have our answer: CI VM probably 4GB
<companion_cube>
Go does it wrong with its 2 return values
<fengb>
Go's error handling has a lot wrong
<fengb>
Not capturing stack traces...
<Tetralux>
Honestly, I like the simplicity of understanding Go's multi-return has.
<mmx87>
Go is like a worse C with safety features and some nice syntactic sugar.
<Tetralux>
It's immediately obvious.
<companion_cube>
Tetralux: simple, and wrong.
<Tetralux>
No complicated stuff.
<fengb>
Single error returns being thrown away
<Tetralux>
I like simplicity.
<Tetralux>
No hidden stuff.
<Tetralux>
And emphasis where it means something.
<companion_cube>
result is not hidden -_-
<Tetralux>
I'd rather Zig's way than Rust's with errors.
<mmx87>
Result is pretty easy when you tried it for a bit.
<Tetralux>
It's just more obvious.
<companion_cube>
Zig's way is pretty similar to rust's result, but baked in
<Tetralux>
And feels more ergonomic.
<mmx87>
It forces you to think what you do wit the result.
<companion_cube>
Tetralux: do you indent with 8 spaces?
<mmx87>
I'm not sure if something like Result woiuld improve Zig.
<Tetralux>
You can also do run(...) catch ...
<Tetralux>
Which prob helps a lot.
qazo has joined #zig
<Tetralux>
companion_cube: I do not.
<companion_cube>
then I'm not sure why you're so scared of indentation :3
<Tetralux>
It reads better to me to have as little movement to right as possible.
<mmx87>
4 spaces > everything else
<Tetralux>
Possibly because I don't wanna judge which indent is which.
<Tetralux>
If there's <3, it's pretty trivial.
<mmx87>
Seeing indent is easy.
<Tetralux>
Not for me ^.^
<mmx87>
You should try to program a week in Lisp.
<Tetralux>
Not when you have like 5.
<companion_cube>
heh, don't look at my code then :D
<mmx87>
It basically forces you to focus on indent.
<fengb>
The only additional thing I wish Zig error handling had is capturing context
<andrewrk>
there's a proposal open for that which I am considering
<Tetralux>
fengb: Isn't that exceptions at that point?
fu5ha has joined #zig
qazo has quit [Read error: Connection reset by peer]
<fengb>
Without magical throws
<Tetralux>
I think Zig just does a better job at communicating what it's error stuff is all about and what mental model to use for control flow.
<companion_cube>
so I have code with 10 levels of indent, can't find more in this codebase ;)
<Tetralux>
Whereas in Rust it just felt like a swamp that I was trying to swim through.
<mmx87>
It depends on how you define context.
<fengb>
Honestly, most grievances of exceptions are the hidden control flow. And most "fixes" are reimplementing exceptions in a weird, half-baked way
<Tetralux>
companion_cube: I'm curious what that code is doing.
<Tetralux>
fengb: I'd rather just multiple-return with an error enum.
<fengb>
Go is probably the worst offender
<scientes>
how is @import("builtin") generated?
<companion_cube>
a bunch of algorithmic stuff. It's just in a language with lots of expressions
<andrewrk>
scientes, there's a function in codegen.cpp
<andrewrk>
define_builtin_compile_vars
<Tetralux>
companion_cube: I'm curious - what do you think is the one syntactic thing that would reduce those indents in that case.
<companion_cube>
absolutely nothing
<Tetralux>
Like - being able to shadow a previous optional that wasn't null?
<companion_cube>
I mean, if it were C, I'd have to replace a 20 lines function with 300 lines
<Tetralux>
Or is just literally just if (x) { thing(); if (y) { thing2() .. etc?
<companion_cube>
(because it's nested matches and higher-order functions and stuff like that, it could be more shallow if I named more stuff)
<companion_cube>
there's like one level which could be removed if `match` wasn't so braindead
<Tetralux>
The fact you have THAT many indents with indent-2 is already too much for me xD
<Tetralux>
Although, that does look better than Rust.
<Tetralux>
So
<Tetralux>
There's that.
<companion_cube>
it'd look quite similar in rust, except with 4 spaces
<Tetralux>
Hence worse XD
<Tetralux>
Also I MIGHT have to steal your colors by the way x)
qazo has joined #zig
<companion_cube>
wombat256mod for vim
<mmx87>
Usually handling results doesn't change the indentation level.
<mmx87>
If you just want to bubble them up you write result?
fu5ha has quit [Remote host closed the connection]
<mmx87>
Also, Rust has the if let syntax.
<Tetralux>
For me, Rust has too much friction for me to use it for daily coding.
<Tetralux>
I just want to get to a compiling program as quick as possible and write in the hackiest way.
<Tetralux>
So I can figure out what I want and how I want to do it
<Tetralux>
Only to then rewrite it better later.
<Tetralux>
(If necessary.)
fu5ha has joined #zig
<Tetralux>
OR
<companion_cube>
so why don't you write C? :p
<Tetralux>
Is just easy to write stuff that isn't very hacky.
<Tetralux>
Because...
<Tetralux>
That...
<companion_cube>
(or D, actually)
<Tetralux>
Just..
<Tetralux>
OH
<Tetralux>
D doesn't have struct inheritance.
<Tetralux>
Only classes.
<Tetralux>
AND A GC.
<Tetralux>
I'm not figuring out how to turn that off reliably. x)
<Tetralux>
Can you even?
qazo has quit [Read error: Connection reset by peer]
<companion_cube>
@nogc
<Tetralux>
I don't want it in my program. Period.
<Tetralux>
No GC.
<Tetralux>
NOPE.
<Tetralux>
NADDAH.
<Tetralux>
I'd rather write my own that I know what tradeoffs it makes and when xD
<Tetralux>
And if I'm doing that I'd rather just not have it.
<Tetralux>
Plus it's not that hard to manage it myself.
<mmx87>
A GC is fine if your programming language isn't a system programming language and you just write stuff quickly.
<Tetralux>
There is SOME truth to that.
<Tetralux>
Except that
<mmx87>
Though a GC can be very horrible.
<Tetralux>
It takes so little effort to manage it myself
<mmx87>
See Java on phones.
<mmx87>
Lol
<Tetralux>
That I really don't care enough.
<mmx87>
Now they need 10GB of RAM.
<mmx87>
That's insane.
<Tetralux>
"Solve problems I care about." - You know?
<companion_cube>
so you never have any memory issue? hat off
<Tetralux>
Yeah - I might have to write an OS specifically to replace Android but that can run Android apps or something.
<Tetralux>
I have more with GCs than without xD
<Tetralux>
Plus they're slower to close my program.
<companion_cube>
that's kind of surprising
<Tetralux>
Because they're busy releasing everything that the OS is gonna dump anyway.
<companion_cube>
you can always call `exit(0);` at the end ;)
<Tetralux>
I COULD just not have one xD
<Tetralux>
Also - when I say "I have more than without" - maybe that's exaggarating a little bit ;P
qazo has joined #zig
<Tetralux>
But I want to have control over those things by code that I know what it's doing.
<Tetralux>
With a GC, you can still read nullptrs. And a general purpose allocator does the same job as a GC really.
<Tetralux>
Like - The tradeoff just isn't worth it.
<Tetralux>
All that code, for something that one call to malloc, or one arena allocator or whatever could handle just fine.
qazo has quit [Read error: Connection reset by peer]
<Tetralux>
And it could stop my world.
<companion_cube>
(some GC'd languages don't have null pointers…)
<Cadey>
eh
* Cadey
shrugs
<Cadey>
different tools do different things
<mmx87>
Null pointers have nothing to do with GC TBH.
<Cadey>
i find a GC is better for a lot of my usual programming style because i fire and forget memory allocations
<mmx87>
They're still useful even if you have a GC.
<Cadey>
having a way to represent nothing vs zero is useful in certain cases
<Tetralux>
mmx87: Eh, maybe not.
<companion_cube>
Cadey: Option<T>
darithorn has joined #zig
<Tetralux>
Cadey: For fire and forget, I'd just malloc anyway.
<Cadey>
companion_cube: my point stands still
<mmx87>
Tetralux, please don't design my next programming language :P
<Tetralux>
Or allocate a bunch of blocks and be done with it. Like how ArenaAllocator does it maybe.
<Tetralux>
mmx87: #StreamOfConsciousness. ;p
<halosghost>
upon reaching the realization that having a safe memory allocator is enough to make use-after-free and double-free into bugs instead of vulnerabilities, I was pretty much sold on the idea that GC should just go away
<halosghost>
plus, `defer` makes “manual” memory management so much simpler
<Tetralux>
halosghost: THERE! That's basically what I was trying to say. x'D
<Tetralux>
Sometimes...
<Tetralux>
Sometimes I feel stupid.
<companion_cube>
how safe can the memory allocator be? would it never reuse a memory slot ever?
<halosghost>
anyone who says malloc/free is “manual” probably hasn't interacted with mmap
<scientes>
all tests passing on linux !
<Tetralux>
companion_cube: Virtual memory.
<Tetralux>
128TB is a lot to use.
<halosghost>
companion_cube: all it needs to do is make sure that once a bit of memory has been allocated for a particular type, that it is only ever used for that type again (for the duration of the execution)
<companion_cube>
(you need it to be tied to a typed language, not C, though)
<halosghost>
C would be fine so long as you're remembering the types and caring about them more than older standards did
<halosghost>
but yeah, a more powerful type system would make that better
<companion_cube>
not sure how you'd do that without any form of generics
<daurnimator>
halosghost: doesn't really work if you have a union member
<andrewrk>
scientes, there's a crash in the behavior tests in release safe mode
<halosghost>
daurnimator: sure it would; it'd just be tagged with the union type
<halosghost>
so, any of the types that allow access to that region of memory would be valid for future allocations
<halosghost>
(I should also mention that “just” is a four-letter word and though what I'm talking about above isn't tremendously difficult, none of it is trivial)
<halosghost>
(though, I would argue implementing a type-safe memory allocator is likely simpler than implementing a GC that performs reasonably well)
<halosghost>
companion_cube: as for without-generics, it could probably be done with some macro magic and _Generic
<halosghost>
though, that wouldn't exactly be pleasant
<halosghost>
it'd certainly be much more pleasant if you had access to something like Zig's @typeInfo
<Tetralux>
If I was gonna write a type-based allocator, def in a lang with typeInfo.
<Tetralux>
Not even attempting that otherwise.
<companion_cube>
especially since you could already do some decisions at comptime based on the type's size, yeah
darithorn has quit [Remote host closed the connection]
<halosghost>
but yeah, with use-after-free and double-free demoted to bugs, you could enable range checks on array access (or use some wide-pointer tricks to guarantee safe array access), and you have the vast majority of memory safety errors handled
<halosghost>
no-gc needed
<halosghost>
:)
mawaldne has quit [Ping timeout: 260 seconds]
<halosghost>
personally, I like the wide-pointer tricks because they're backwards-compatible and incredibly compact
<halosghost>
I wish wide-pointers had much wider support
<halosghost>
):
<companion_cube>
having more defensive allocators sounds awesome for security sensitive applications
<fengb>
I'm really happy that Zig supports custom allocators as a design goal
johnLate has quit [Ping timeout: 245 seconds]
johnLate has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<halosghost>
indeed
<zie>
what would also be really awesome for security sensitive apps is a way to easily check variable assignments for custom constraints..
<zie>
like the postgresql CHECK keyword for example.
<halosghost>
not to pick a fight (because postgres is one of the most standard-philic of the SQL engines), but check constraints are part of standard SQL :)
<halosghost>
and yes, smart constructors are very cool
<halosghost>
some really high-level languages (like Haskell) have them
<halosghost>
I'm not aware of any lower-level languages that have smart constructors
<zie>
halosghost :) indeed. Well Haskell has Liquid Types, which mostly does that.
<halosghost>
unless you count OOP languages where you can do almost anything in teh constructor
<halosghost>
zie: oh, I didn't even mean Liquid; I just meant plain old smart constructors
<zie>
but as far as I'm aware, it's not integrated or part of the language.
<zie>
halosghost oh?
<halosghost>
zie: it's up to the type implementer to leverage it
<companion_cube>
isn't it the case of any language that has reasonable type abstraction?
<halosghost>
roughly, the way it works is that you don't export the regular data constructors, just the smart constructor functions; i.e., you can only make a new thing via the function that does checks to verify that you're doing sane things
<halosghost>
companion_cube: I guess it depends on how you categorize that :)
<Tetralux>
That just sounds like a constructor fn to me :)
<companion_cube>
if you can force a type to be constructed only via certain functions
<halosghost>
companion_cube: you mostly can in Haskell anyway :)
<halosghost>
Tetralux: I suppose
<companion_cube>
and in OCaml
<halosghost>
companion_cube: cool :)
<halosghost>
I've been meaning to learn ocaml
<companion_cube>
(you can make a type definition readable by all, but constructible only via functions from the same module)
* halosghost
goes to check the zig issue tracker to see if things like linear types are planned for zig
* halosghost
thinks the answer is no
<halosghost>
doesn't look like it
<halosghost>
not sure it'd be helpful in Zig anyway :)
<andrewrk>
async/await futures are linear, and that's not planned to change
<andrewrk>
but the concept is not exposed to userland
<zie>
"This check will be carried out at runtime, once, when the value is built." -Haskell, which severely limits the checks, unless you always do immutable types.
<halosghost>
andrewrk: linear as in “use only once”?
fengb has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andrewrk has joined #zig
qazo has joined #zig
brakmic has joined #zig
<andrewrk>
scientes, I think this one is going to pass
<halosghost>
:D
halosghost has quit [Quit: WeeChat 2.5]
dimenus has joined #zig
<dimenus>
andrewrk: do you prefer support on patreon or do you have another method as well?
<andrewrk>
for now patreon is all I have. in the near future I hope to use github sponsors, and more in the future I hope to have started a non-profit org
<companion_cube>
do you have any plans for after 1.0?
<andrewrk>
then I want to make a bunch of cool stuff! programming, instead of meta-programming
<companion_cube>
😁
<andrewrk>
I might do a game, or pick back up my digital audio workstation
<THFKA4>
hope you get into the github beta to get those sweet sweet matching bucks
fengb has joined #zig
<andrewrk>
long term plan is to potentially make the non profit org do some consulting, and contract people to do zig coding
<andrewrk>
I'd love to be able to pay people to work on zig stuff
<companion_cube>
any dreams of standardization?
<andrewrk>
you mean besides a language specification?
<andrewrk>
(which is planned)
<daurnimator>
zie: there's a proposal around (in a comment that I can't find) that makes it so that arguments/types can be declared as `somefunc` where somefunc is a function that takes a type and returns a bool
darithorn has joined #zig
<companion_cube>
like an ISO standard, somewhere in the future
<andrewrk>
emekankurumeh[m], that's what I mean about parts 2 & 3. in that example, the result is still copied
<andrewrk>
because there is a `var result` - that creates a stack variable
<andrewrk>
and so the `return result` - you can follow the result location: the `return` refers to the non-copying result location. but then the `result` variable gets copied into that result location
<andrewrk>
I'll write this stuff up
<mikdusan2>
i think the "surprise" here is init() stays the same. it's the call site that chooses if it's a stack or heap destination
<andrewrk>
I don't know the order of parts 2 & 3 but part 2 is ability for the return result location to be used throughout the function rather than just in the return expression. and part 3 is unwrapping error unions & optional return types so that the underlying payload is not copied
FireFox317 has joined #zig
<andrewrk>
what is about to change is "result location" not "copy elision". Every expression, you can see where the result location flows from outside the expression inwards
<FireFox317>
andrewrk: Nice job with the copy ellision branch, I laughed about the video you just posted
<daurnimator>
andrewrk: hit that merge button already ;)
<andrewrk>
but nobody reviewed the code
<andrewrk>
j/k
<daurnimator>
andrewrk: yay
<daurnimator>
> 16 of 19 tasks complete
<daurnimator>
:sweats
<mikdusan2>
make 19 immutable
<daurnimator>
andrewrk: go have a beer
<daurnimator>
andrewrk: and then back to the code mines to merge PRs and then work on #2377 ;)
<Tetralux>
"Houston, I am ready and waiting to press the button." - Or in my case command line.
<andrewrk>
\o/
<Tetralux>
XD
marijnfs__ has quit [Ping timeout: 252 seconds]
FireFox317 has quit [Ping timeout: 260 seconds]
marijnfs__ has joined #zig
<andrewrk>
I can't wait to delete all this garbage coroutine code
<daurnimator>
andrewrk: so I'm re-reading #2337 now. I like the @Frame idea. But I'm unsure why calling an function returns the frame. That seems undesireable from a #1778 POV
<daurnimator>
and apparently my spelling/grammar has failed for the day
<emekankurumeh[m]>
+1 for doing a write-up on copy elision
<emekankurumeh[m]>
tbh i'm kinda confused by what "result location means"
<daurnimator>
emekankurumeh[m]: see #2377 for a short explanation
<daurnimator>
> What actually ends up happening is that hi gets a secret pointer parameter which is the address of w and initializes it directly.
<scientes>
I'm going to need to figure out how to actually use the inline assembly if am to get a number of things done
<scientes>
the error messages are so cryptic and i am not the only one with this problem
<scientes>
tgschultz has the same problem
darithorn has quit [Quit: Leaving]
wootehfoot has quit [Read error: Connection reset by peer]
vexu has quit [Ping timeout: 244 seconds]
dimenus has joined #zig
fengb has joined #zig
<andrewrk>
scientes, there's a missing feature to connect the error messages back to zig source
<andrewrk>
it's pretty bad, I wouldn't do any inline asm work debugging without implementing it
<scientes>
oh so llvm gives decent error messages?
<andrewrk>
you're seeing llvm's error message but it's missing context