3 ms·
What you say about dynamic dispatch also applies to regular function calls, which is why I'm disappointed that Zig provides no visible distinction at the call s
by kps 3y ago
What you say about dynamic dispatch also applies to regular function calls, which is why I'm disappointed that Zig provides no visible distinction at the call site between direct and indirect calls (as K&R C did but ANSI C made optional).
I understand the desire for magic-indirection ergonomics; I just don't think the tradeoffs work out the same for code vs data.
- hansvm 3y agoIf the function is comptime-known then you'll get a direct call, and you can mark it near the call site as being required to be comptime-known (e.g., by marking a function argument to another function with the "comptime" tag). To make it super explicit you can make a no-op function like `fn cknown(comptime f: anytype) @TypeOf(f) {return f;}` and then replace stuff like `foo(bar)` with `cknown(foo)(bar)`. It's a tiny bit harder to force an indirect call if that's desired for some reason; I think you'd need to write a slightly longer never inlined helper function to strip the constness from the pointer. It's doable though, just not directly provided by the language.
- kps 3y agoWhat I had in mind is the programmers' view of the code: in K&R C, every function call was visibly either direct or indirect, `f()` or `(*f)()`. My main concern is not actually performance, but comprehensibility: an indirect call is a conditional branch, where the condition can be arbitrarily far away in space and time and is not statically determinable, so it should not be invisible. I appreciate that this doesn't fit Zig's call syntax, which is unlikely to change, so the long-term best case is probably some LSP marking based on the callee type.
- nyberg 3y agohttps://github.com/ziglang/zig/issues/6966 https://github.com/ziglang/zig/issues/6966 was discussed