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 quit []
aiwakura30 has joined #zig
aiwakura30 is now known as aiwakura
darithorn has joined #zig
davr0s has joined #zig
suirad has quit [Ping timeout: 256 seconds]
darithorn has quit []
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…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
fsateler has quit [Ping timeout: 276 seconds]
very-mediocre has joined #zig
fsateler has joined #zig
hio has joined #zig
Hejsil has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<hio>
is there an issue that explains the new struct syntax with the . dot?
<hio>
just interested to read about the reasoning here
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Hejsil>
It's still being talked about, and people are proposing other solutions. I still think what we have now is pretty good, and it has some syntactic similarities with .? and .*
<hio>
ok thanks, btw I will propose to make a name change from struct to type. Structs are just types, even the error messages call them types when they refer to them.
<Hejsil>
enum/union/struct/error/i32 etc are all types
<Hejsil>
So that wont work
<hio>
aaargg but it would look so much better :(
<Hejsil>
It would?
<Hejsil>
I think struct makes perfect sense here. Why would we use type.{} for structs, but not for union.{}? What makes struct more of a type than union? :)
<hio>
ok I will try to think of it differently
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
davr0s has joined #zig
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
hio has quit []
<very-mediocre>
For #760 I think you're on to something Hejsil, when you say that `error` should just always require braces
<very-mediocre>
and your suggestion of `anyerror` could be something like `error.*`
<Hejsil>
I actually have an idea, where the only "real" syntax change from 0.3.0 would be to change `error` to `anyerror`, or something like that
<Hejsil>
I think we can split expressions into TypeExpr and NonTypeExpr
<very-mediocre>
this makes much more sense than the other solutions imho
<very-mediocre>
i think the other approaches are looking at the problem backwards, it's a problem with error being ambiguous, rather than function declaration syntax being ambiguous
<very-mediocre>
I can't think of any other situation where {} is optional
<Hejsil>
A TypeExpr, is an expression that could evaluate to a type: []NonTypeExpr, [N]NonTypeExpr, [*]NonTypeExpr, *NonTypeExpr, NonTypeExpr!NonTypeExpr, <container_keyword> {}, NonTypeExpr . Symbol, NonTypeExpr (<params>)
<Hejsil>
Note here, that an initializer is not a TypeExpr
<Hejsil>
There are more, but this is the basic idea
<Hejsil>
There is no way a initializer can ever return a type
<Hejsil>
Or... Hmm, I'll think about it some more, but im pretty sure this can work
<Hejsil>
There are syntaxes that can return a type and syntaxes that can't, basically
<Hejsil>
expr + expr can never return a type
<Hejsil>
a{.a = 1} can never return a type
<very-mediocre>
Yeah, it all makes sense to me
<Hejsil>
A.B can, a() can, an so on
<very-mediocre>
and it seems infinitely more appropriate than changing the way functions are declared in general
<Hejsil>
After I come up with a gramma, I could generate a parser, and see if it can parse the entire std. If so, then there is no breaking changes
<very-mediocre>
Interesting approach
<Hejsil>
Then I could implement the grammar in stage1 and stage2
<very-mediocre>
I have no experience with such tools though
<very-mediocre>
I have no idea if they're reliable
<very-mediocre>
It might be easier to roll your own test that's tailored for zig, since all this does is generate all variations of known syntax constructs
<Hejsil>
Idk about cfg-checker, but I've used parser generators before, and they are good
<very-mediocre>
sadly this is one of those areas I never had time to dig into other than academically (we did a Lisp)
<very-mediocre>
a lot of people prototype languages using generators, then once they come up with something stable, reimplement it as self hosted
very-mediocre has quit [Ping timeout: 256 seconds]
very-mediocre has joined #zig
Hejsil_ has joined #zig
Hejsil has quit [Ping timeout: 256 seconds]
Hejsil_ is now known as Hejsil
very-mediocre has quit [Ping timeout: 256 seconds]
very-mediocre has joined #zig
geemili has joined #zig
Hejsil has quit [Quit: Page closed]
<MajorLag>
hmmm "cannot store runtime value in compile time variable" thrown on a const assignment from a comptime fn called on a comptime variable... in a comptime block. I don't know how to comptime harder.
Hejsil has joined #zig
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
darithorn has joined #zig
Ichorio has joined #zig
Hejsil has quit [Ping timeout: 256 seconds]
andrewrk has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
porky11 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ichorio has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
MajorLag has quit [Ping timeout: 250 seconds]
davr0s has joined #zig
jayschwa has joined #zig
MajorLag has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
porky11 has quit [Quit: Leaving]
<MajorLag>
If we have `@OpaqueHandle(T)`, should we do away with `@OpaqueType()` since it would be identical to `@OpaqueHandle(*c_void)`?
<andrewrk>
I don't think that's quite right. an opaque handle has a known size. @OpaqueType() makes a type with an unknown, but non-zero, size
<andrewrk>
c_void itself is defined as @OpaqueType()
<MajorLag>
But there's no reason I couldn't make, say, an `@OpaqueHandle(*MyStruct)` right? It seems there's significant overlap with `@OpaqueType` to me.
<andrewrk>
That's right. I agree about the overlap. I think this is related to my question on the issue - in a pure zig codebase, would there be a reason to use @OpaqueHandle?
<andrewrk>
that question applies to @OpaqueType() as well