Abolish callconv, implement its functionality across extern

[ghost]

Complement to #6057, in some ways.

With #1717, extern const foo = fn ... will be distinct from const foo = extern fn .... This provides us a marvelous opportunity to unify aspects of extern.

I propose that extern on the left will mean the function is externally defined, whereas extern on the right will fit with its meaning when used on other types (union, enum, struct): it sets the ABI of the function. To have parity with current callconv features, we would also need to allow ABI specification on the right: const foo = extern "eabi" fn ...; we may do this without syntactic ambiguity, as the second argument must begin with fn, union, enum, or struct, and the first may not. Note that two externs will never appear on the same line, as left extern precludes a definition.

As for compiler-internal CCs:

• .Zig -- no annotation necessary, as it is the default.
• .Async -- explicitly marking functions as async was previously possible and then explicitly rejected. Switching between synchronous and asynchronous based on argument is also a bad idea, for the same reason: the compiler should work that out.
• .C -- default of extern, also possible with extern "c".
• .Naked -- grrr. This is annoying. Personally, given the vast functional and safety difference of naked and non-naked code, I think a keyword is the best option, like the old nakedcc (personally I'd prefer naked, but that's opinion).

[LemonBoy]

This conflicts with the awesome #5269 proposal.

I propose that extern on the left will fit the current definition of extern fn, whereas extern on the right will fit with its meaning when used on other types (union, enum, struct): it sets the ABI of the function.

So extern const foo = extern fn (...) has two extern on the same line with two different meanings? How is that a good idea?

const foo = extern "eabi" fn ...

This syntax is already taken to specify what library the extern belongs to.

[ikskuh]

I agree with LemonBoy that #5269 is the better propsal here. It removes a ambiguity of the keyword extern

[ghost]

So extern const foo = extern fn (...) has two extern on the same line with two different meanings?

This is not possible -- extern on the left means the function is externally defined, so it cannot have a definition; so, two externs will never appear in the same statement. I suppose that should have been explicit.

I suppose this proposal leans into the multiplicity of extern, but there is no ambiguity: the placement of extern uniquely determines its meaning. Also, unless #5269 plans to remove extern (union|struct|enum), this multiplicity still exists within the language, and by the way extern still means "conforming to the C abi" by default.

[LemonBoy]

This is not possible -- extern on the left means the function is externally defined, so it cannot have a definition; so, two externs will never appear in the same statement. I suppose that should have been explicit.

That was just an example, here's an amended one:

extern const foo;
const bar = extern fn (...)

I suppose this proposal leans into the multiplicity of extern, but there is no ambiguity

The ambiguity is still there, the first extern refers to the variable linkage while the second refers to the calling convention.

Also, unless #5269 plans to remove extern (union|struct|enum), this multiplicity still exists within the language

Have a look in the tracker, there are a few proposals for this.

[ghost]

Yeah, this is a horrible idea.