ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
atk has quit [Quit: Well this is unexpected.]
atk has joined #zig
wryun has quit [Quit: wryun]
<cgag>
haven't done much c/c++, do a lot of go, how do you guys generally represent multiple return values, just return a struct?
<MajorLag>
cgag, yes. However there's a proposal for tuples (#208), and for multiple return values (#498).
<scientes>
or use out variables with pointers, as is normally done in C
<scientes>
*out arguments
<scientes>
but i'm all for multiple return values
<MajorLag>
Yeah, that is used by some builtins.
<scientes>
so that the functions are pure
<scientes>
which is important for a bunch of optimizations
<MajorLag>
tuples seem like they're pretty likely to happen.
kristate has joined #zig
<scientes>
i'm more for multiple return values
<scientes>
which allows you to switch values without a temp variable
<scientes>
a, b = b, a
<scientes>
multiple assignment too
<kristate>
back online
<scientes>
good morning
mnoronha has quit [Ping timeout: 252 seconds]
<kristate>
morning
<cgag>
actually i guess in my case it's should probably just be an error union anyway, i just did a hacky port of golangs parsefloat and the second return value is a bool for overflow
<cgag>
multiple return values is pretty nice though, would be happy to see that
<scientes>
i think it is important for optimization reasons, allows functions to be labled pure (although that has to be annotated, and there is no way to annotate that AFAIK)
<cgag>
after writing a bunch of rust and go, parens on an if statement feel pretty weird, has dropping those been discussed?
<MajorLag>
I believe it has, but I can't find an issue for it. Personally I find it makes for harder to read code.
kristate has quit [Remote host closed the connection]
kristate has joined #zig
_whitelogger has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<kristate>
andrewrk: I reopened the PR with a patch
<Guest38217>
andrewrk: You were going to elaborate on somethin' or other after dinner a few days back, no?
Guest38217 is now known as dirkson
<dirkson>
Whoops, my name was borked. Fixed.
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
redj has quit [Ping timeout: 240 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hooo has joined #zig
kristate has quit [Remote host closed the connection]
davr0s has joined #zig
hoppetosse has joined #zig
<andrewrk>
dirkson, I believe it was on my ideas for what the stage2 compiler could do
<andrewrk>
which is, in summary, to be a command line IDE with a repl interface, which you would use as the backend for a real ide or a text editor plugin
<dirkson>
Yeah, ok. So it's imagined that you'll need 1) Your compiler (or one implmented very similarly) and 2) a text editor with the ability to interface with this compiler in order to maintain nontrivial zig codebases?
<andrewrk>
that would be one option, but I'm hinting that there would be an alternative (2) which is to use the command line interface of the stage2 compiler and a plain text editor
<andrewrk>
certainly, integration would be nicer
<dirkson>
Hmm, true.
<andrewrk>
but you could accomplish all the same things - refactorings, renamings, finding out the fields of a type
<dirkson>
I'm not being explicit because I disagree, I'm just trying to nail down what level of integration is expected, because that has implications for other language features. This opinion seems consistent with language features I was eyeing suspiciously, though, so that seems good : )
<dirkson>
Is composability of tools a design goal? (I.e. The Unix way of having multiple smaller tools that chat with each other)
<andrewrk>
dirkson, it's hard for me to answer the question at that level of generality. can you give a zig-specific example?
<dirkson>
Well, I was considering whether the compiler and repl could/should be separated. One of the things I observe with other languages is that people create alternative compilers for them at a fairly high rate, for various niche needs. If you want to support that for Zig, separating out the repl would help - It'd allow people to *just* replace the compiler, or *just* replace the repl, without neccesarily needing to
<dirkson>
do both at once.
<andrewrk>
I see
<andrewrk>
I think that alternative implementations would choose to support a different set of features in the zig toolset
<andrewrk>
for example an alternative implementation may not support the --watch flag which enables the repl stuff
<andrewrk>
just replacing the repl wouldn't really work, because it is fundamentally tightly coupled with the compiler
<dirkson>
Hmm. Yeah, ok. I can see separating things at that level, too.
<andrewrk>
that's a bit into the future though. writing the language specification is scheduled for 1.0.0 and we're still at 0.3.0
<dirkson>
True!
<dirkson>
I think, left to my own devices, I'd probably produce some sort of library for parsing Zig code, and just re-use it in the repl and compiler. That way, you support the repl behavior you want without duplicating code, and keeping the repl code separate from the parts of the compiler it doesn't need to understand (I.e. The actual translation of zig code into assembly) while also providing three independent
<dirkson>
projects that all have utility apart from one another. Buuut I tend to lean pretty heavily towards the 'small, composable tools' mindset.
<andrewrk>
dirkson, we have that already
<andrewrk>
std.zig.parse
<andrewrk>
and then for rendering the AST, std.zig.render
<andrewrk>
sorry by "that" I mean some sort of library for parsing zig code
<andrewrk>
as for the other stuff, I guess I'll have to admit that I'm thinking about this a bit of a different way
<dirkson>
Neat! Then I don't think I understand why the repl/compiler need to be so tightly integrated. Clearly, there's a bunch of overlap, but in my head the repl mostly needs to either call the 'parse' bits, or needs to call the 'compile' bits, depending on what you ask it to do.
<andrewrk>
my goal is not really to create composable tools - although I do see the value in those things - but my goal is that the set of use cases that zig is attempting to solve are optimally and ideally solved
<dirkson>
Mmm, you've got the build system integrated into the compiler too. Maybe that's part of it.
<andrewrk>
often these two different goals are in harmony, but sometimes not
<dirkson>
Aye.
<andrewrk>
when I talk about the stage2 compiler repl, I'm describing a system that watches files on disk, and incrementally builds and links a project, keeping all the compiler analysis in memory
<andrewrk>
the IDE features are merely an interface to introspect that state
<andrewrk>
that's why I claim they are tightly coupled
<dirkson>
Yeah. I think the build system is a good example of where composability and other concerns are in conflict. Understanding zig code allows the build system to do tricks that would otherwise be impossible for more traditional build systems.
<andrewrk>
my main goal with the build system is to create a standard, consistent build strategy for zig projects, but more importantly, to remove a dependency on an external build system
<andrewrk>
idea being that even a very big and complicated zig project can potentially only depend on a zig compiler and nothing else
<andrewrk>
fewer dependencies means that more people - both developers and users - will be able to use your project
DutchGh0st has joined #zig
<dirkson>
Naw, that particular argument I don't buy. Given that you can set the license on all thedependencies, and bundle them all together, adding additional dependencies doesn't create any additional issues for devs. By default, people would just depend on the standard Zig Compiler Bundle. But if they needed to, they could pull it apart and replace bits, while only needing to understand simplified interfaces between
<dirkson>
parts. My window manager does this - apt-get install i3 pulls in i3-wm, i3-lock, and i3-panel (Or similar) which all work together nicely. But I can still swap out one of those sub-parts for one I prefer, if I want to.
<andrewrk>
as another example, the biggest reason that people don't contribute to zig is inability to obtain and build the correct version of LLVM
<dirkson>
Sure. Dependencies from another source can be a problem. But the *from another source* is stressed : )
<andrewrk>
agreed
<andrewrk>
so for example GNU Make, and Zig are from different sources
<andrewrk>
therefore a build system coming from the Zig source is meaningful, because it removes a dependency from another source
<dirkson>
Sure. But, from a strictly dependency-issue-oriented perspective, providing the zig-make system as a separate binary or as a separate block of code integrated into the main compiler binary doesn't neccesarily change the minimum complexity to start a zig project.
<andrewrk>
agreed
<dirkson>
You just have other, compelling reasons for integrating the two :)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<dirkson>
Thanks for the chat, and please pardon my attempts to nudge dev work. I wouldn't care so much if I weren't so excited about Zig as a language : )
<andrewrk>
I'm happy to chat with you, dirkson
kristate has joined #zig
bheads has quit [Disconnected by services]
bheads has joined #zig
wilsonk has quit [Read error: Connection reset by peer]
kristate has quit [Ping timeout: 268 seconds]
wilsonk has joined #zig
<wink_>
I improved the zig-benchmark https://github.com/winksaville/zig-benchmark. I added multiple repetitions, added mean, median and stddev and improved the reporting. Love feed and if desired would like to contribute it to the ziglang project.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
redj has joined #zig
hooo has quit [Quit: Page closed]
<hoppetosse>
andrewrk: what's the difference between a c_void and an Opaquetype?
<andrewrk>
hoppetosse, c_void is defined like this: const c_void = @OpaqueType();
<hoppetosse>
And with my PR, the only difference is that ptrs can implicitly cast to c_void, but not other opaque types?
<hoppetosse>
or more correctly, *T will implicit cast to *c_void, but not *@OpaqueType
<andrewrk>
hoppetosse, yes, exactly
<andrewrk>
make sense?
<andrewrk>
like with other C types, c_void generally should be avoided when possible. e.g. you would create a special @OpaqueType for different things
<andrewrk>
but we smooth over interfacing with C, and zig users can increase safety by changing declarations to zig types rather than C types
<hoppetosse>
makes perfect sense, just wanted to confirm the rationale =)
DutchGh0st has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]