Jehanzeb Mirza

I think it's too confusing for an operator to consider context before applying itself. Because as I understand it what your saying effectively amounts to this: ```zig var bar: u8...

I like `@ReturnType()` much better than `@ResultType()`. Its way clearer that the type is inferred from the function return location, wherever that may be.

How about also adding an argument containing the std.builtin.SourceLocation? So a signature more like this: ```zig pub fn panic(cause: PanicCause, error_return_trace: ?*StackTrace, ret_addr: ?usize, source: ?std.builtin.SourceLocation ) noreturn { //...

Why wouldn't the function name and file be reused? Surely it could be done smartly so its only whatever bytes for the function name and the file name and then...

Here is an example of what I mean. This is roughly how the panic could work at the implementation level. Not embedding the full source struct in every panic location....

I don't like this solution. I believe it is both a bit ugly, and also it solves the problem in a way that is only useful for exactly this use...

I also believe my counter proposal could be useful for other cases. inline else is a bit restrictive although it can be used in a similar way. Inline else is...

This whole thing is actually one of the parts of Zig having aliasing problems. Simply fixing it so it works with slices just moves the pitfalls somewhere else. Register allocation...

Not yet I believe. https://github.com/lifan0127/ai-research-assistant/issues/144#issuecomment-2480672629