Open andrewrk opened 2 years ago
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 fn foo
or pub fn foo
. Maybe that will be broken by #1717 anyways and that concern is irrelevant, but I thought it worth mentioning.
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?
I think this should stay consistent with align()
expressions on struct fields, which don't have a var
/const
keyword potentially making the proposed change awkward.
drop the
callconv
keyword?
How would you pass a function pointer to a C function without exporting it as a symbol?
@andrewrk Shouldn't callconv
go before the fn
keyword, like all other function modifiers? (except for align
, for some reason)
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 callconv
be be moved in order to make this change? Why is there an ordering requirement for parameter visibility anyway?
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 fn (...) callconv(x) T
until reading this post and the placement of it has always felt really unintuitive to me (which isn't the placement used in the first post? callconv goes before the return type unless that was changed but the grammar in the langref says otherwise), so I support this change along with dropping the keyword entirely. I don't think it should affect "greppability" either as #1717 will break it anyway plus fn.+name
does the job just fine.
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.
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 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.
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 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