9 ms·

On a cursory look at the problematic examples, this seems to be an issue with Zig’s type system. There are async functions and non-async functions, and they hav

by amluto 5y ago

On a cursory look at the problematic examples, this seems to be an issue with Zig’s type system. There are async functions and non-async functions, and they have the same syntax, but they have what should be different inferred types. But Zig allows pointers to both to be stored in the same array without an obviously unsafe cast, and the result doesn’t work. ISTM this could be fixed in the type system, possibly at the cost of breaking some existing working code.

MrBuddyCasino 5y ago
Sounds about right. Zig couldn’t claim to be colorless anymore, but this seems like an unsound type system to me. Still think Zig‘s approach is a step into the right direction. Is the JVM the only remaining runtime that properly fixes the issue?
anonymoushn 5y ago
There seems to be a defect in the type inference. In TFA's programs, using (but not calling) red gets you a value of the wrong type. Adding an explicit callconv(.Async) to red causes you to get this error: ./src/main.zig:42:32: error: expected type 'fn(*u64) void', found 'fn(*u64) callconv(.Async) void' const fns = [2]@TypeOf(blue) { red, blue }; After that, changing the array to be an array of @TypeOf(red) gets you a working program. That is, it's apparently fine to store blue in a value of red's type and use blue with @asyncCall as if it was red's type at runtime, but trying to store red in a variable of blue's type is a compile error. here's a gist demonstrating this stuff that a user posted in the Zig Discord: https://gist.github.com/sharpobject/49bd88416e68606d7812d609831cc8ae https://gist.github.com/sharpobject/49bd88416e68606d7812d609...
- amluto 5y ago
  Hmm, seems like it’s maybe not in type inference per se. It seems more like the compiler actually believes that red (used as a function pointer) is not async! So it has the wrong type in @TypeOf and it also coerces itself with no warning to that wrong type. Ouch.
  - anonymoushn 5y ago
    The docs are light on details, but the compiler should figure out that red is async, and it does if you call it, but not if you take a pointer. I would describe this as a defect! We don't actually disagree about any facts though, just labels.

by amluto 5y ago

MrBuddyCasino 5y ago

Sounds about right. Zig couldn’t claim to be colorless anymore, but this seems like an unsound type system to me. Still think Zig‘s approach is a step into the right direction. Is the JVM the only remaining runtime that properly fixes the issue?

anonymoushn 5y ago

There seems to be a defect in the type inference. In TFA's programs, using (but not calling) red gets you a value of the wrong type. Adding an explicit callconv(.Async) to red causes you to get this error: ./src/main.zig:42:32: error: expected type 'fn(*u64) void', found 'fn(*u64) callconv(.Async) void' const fns = [2]@TypeOf(blue) { red, blue }; After that, changing the array to be an array of @TypeOf(red) gets you a working program. That is, it's apparently fine to store blue in a value of red's type and use blue with @asyncCall as if it was red's type at runtime, but trying to store red in a variable of blue's type is a compile error. here's a gist demonstrating this stuff that a user posted in the Zig Discord: https://gist.github.com/sharpobject/49bd88416e68606d7812d609831cc8ae https://gist.github.com/sharpobject/49bd88416e68606d7812d609...

amluto 5y ago
Hmm, seems like it’s maybe not in type inference per se. It seems more like the compiler actually believes that red (used as a function pointer) is not async! So it has the wrong type in @TypeOf and it also coerces itself with no warning to that wrong type. Ouch.
- anonymoushn 5y ago
  The docs are light on details, but the compiler should figure out that red is async, and it does if you call it, but not if you take a pointer. I would describe this as a defect! We don't actually disagree about any facts though, just labels.