zig build mistakens Struct fn for @EnumLiteral() when there's catch clause #31952

Zig Version

both 0.16.0 and 0.15.2

Steps to Reproduce and Observed Behavior

const std = @import("std");
const Io = std.Io;
const Context = struct {
 a: *[4096]u8,
 pub fn init(gpa: std.mem.Allocator) !@This() {
 const p = try gpa.create([4096]u8);
 return .{ .a = p };
 }
 pub fn deinit(self: @This(), gpa: std.mem.Allocator) void {
 gpa.destroy(self.a);
 }
};
pub fn main(init: std.process.Init) void {
 const context: Context = .init(init.gpa) catch @panic("context init failed");
 defer context.deinit(init.gpa);
 std.debug.print("{any}\n", .{context});
}

zig build run gives error:

src/main.zig:16:31: error: type '@EnumLiteral()' not a function
 const context: Context = .init(init.gpa) catch @panic("context init failed");

Looks like the compiler think .init is a @EnumLiteral() when there's catch clause. use Context.init or remove the catch clause and use a try would works.

Expected Behavior

compiles success.

I have a similar issue with this snippet at the container level (file):

constlib_ver:SemanticVersion=.parse(lib_ver_str)catch@compileError("'"++lib_ver_str++"' is not valid semantic versioning");

type '@EnumLiteral()' not a function (referring to .parse)
Removing the type annotation and turning the declaration literal into a regular namespaced function call compiles and has the desired behavior.

constlib_ver=SemanticVersion.parse(lib_ver_str)catch@compileError("'"++lib_ver_str++"' is not valid semantic versioning");

The latter is also the unofficially the preferred syntax.
IIRC this is due to issues regarding Peer Type Resolution, or Least Upper Bound.
If I'm indeed not mistaken one could take a look at this GitHub issue.

This is expected behavior with "decl literal" syntax; see the discussion and release notes draft on the original PR here: https://github.com/ziglang/zig/pull/21264

Currently, this is considered the expected behavior, because at present only the try operator allows specifying a result type, while catch does not provide one.

What can possibly be done before the relevant implementation gets support is to improve the error messages.

Off topic: Although Peer Type Resolution is considered the reason why catch cannot pass result types, I once tried to give an example that could cause ambiguity because of this, and eventually found that similar examples could exist in try, which can handle them properly. So, in fact, I am not sure what the specific example is that causes catch to be unable to pass result types.

@npc1054657282 wrote in #31952 (comment):

Off topic: Although Peer Type Resolution is considered the reason why catch cannot pass result types, I once tried to give an example that could cause ambiguity because of this, and eventually found that similar examples could exist in try, which can handle them properly. So, in fact, I am not sure what the specific example is that causes catch to be unable to pass result types.

What confuses me the most is that in both OP's example and mine, the syntax is const x: X = .decl(...) catch y, with @TypeOf(y) == noreturn
Maybe special casing this could be an improvement?
I get why catch can't provide a result type for the general case: error sets must be compared with the function's returned error union type.
But in practice, I feel like noreturn should be special, because I assume one is not trying to keep the result type when catching some expression of type noreturn in an assignment. Especially since in this case, we're not in any function scope.
We can already do this: const a: u32 = if (some_condition) some_u32 else some_expr_of_type_noreturn, so not being able to do what OP described seems rather inconsistent.
To quote langref :

When resolving types together, such as if clauses or switch prongs, the noreturn type is compatible with every other type.

I am sure there is something I'm missing, but as a programmer, moving the type to rhs to not use decl literals and having the problem suddenly fixed does not feel like an intended feature at all and more like a technical limitation or a quite hacky solution. It also goes against the unofficially preferred syntax with the type being explicit.