-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make callconv not have comptime parameters in scope #11834
Comments
I'm all for language simplifications and don't know of any use-case for using comptime parameters to determine the calling convention. However, changing the syntax in this way has one downside that is in my opinion significant: it breaks grepping for
I think this should stay consistent with |
How would you pass a function pointer to a C function without exporting it as a symbol? Incase it's helpful, here is all ~1,000 usages of `callconv` in Bun. Majority of this is from `zig translate-C`, but not all
|
@andrewrk Shouldn't pub callconv(.C) fn foo(comptime a: u16) void rather than pub fn callconv(.C) foo(comptime a: u16) void |
i think not changing the grammar is the right move |
Is it really necessary that |
Sorry for the late bump but I don't think the idea is that it's necessary to move it to make the change, but rather that the syntax should reflect the new semantics, which it should. I actually had no idea why it was |
I might be misreading, but does that mean a pattern like this would no longer work? Where alignment is a comptime argument? pub fn copyU8IntoU16WithAlignment(comptime alignment: u21, output_: []align(alignment) u16, input_: []const u8) void {
} |
I think what is actually meant is that this wouldn't be allowed: fn alignedFunction(comptime alignment: u29) void align(alignment) {} |
This proposal has been split into two proposals: |
This is currently supported by self-hosted:
I think the language should be simplified so that align and callconv expressions come after the
fn
keyword and it should not be possible to use comptime parameters in their expressions.One motivation for this is that when semantically analyzing a function call, we want to know whether to inline call it or whether to create a generic function instantiation. Finding out after a generic function instantiation that it is inline is too late.
Related question is whether to do the same thing for
align()
expressions. And if so, shouldalign()
expressions on variables be moved to after thevar
keyword too?Another related question: drop the
callconv
keyword?Related: #4630
The text was updated successfully, but these errors were encountered: