Meghan Denny

related, `infer` keyword is proposed here too, the syntax actually pairs pretty well

the same you'd get with the cast builtins: `error: @intCast must have a known result type` and `note: use @as to provide explicit result type`

for instance if a package provided a module in `build.foo.zig` so as to not interfere with an incompatible root `build.zig` then users might be able to pass `.build_file = "build.foo.zig",`...

https://gist.github.com/nektro/a28d4aadca050d32ab8ea5723bcb6739 the expected output of cloning this and running `zig build run` is: ``` info: 184 info: 486 ```

another better alternative to the exact code i provided is if `.build_file = "build.zig.zig",` could be read from the zon of the package being depended on, rather than having to...

because that logic uses the cache but needs to be callable by `build-exe` etc. making them use the actual build system is a good idea imo but will require a...

does this proposal being implemented mean for example that `zig reduce` would start shipping as `zig-reduce` and/or the `zig` binary should check PATH for binaries to ensure the space version...

its not ambiguous, `catch` takes precedence and the compile error is there if the return type is `!u32` for example. in @dylan-conway's example the compile error should be `error: expected...

edit: `try` does appear to be the one to actually take precedence in the `!u32` example so it should perhaps be `error: unreachable code` in both cases. this is consistent...

yes it does make sense, i was not trying to say `!noreturn` should be disallowed. only agreeing that attempting to `try` *and* `catch` it should be a compile error like...