Proposal: remove implicit callconv(.C) on extern functions

[tadeokondrak]

Currently, these do the same thing:

0. extern fn foo() void;
1. extern fn foo() callconv(.C) void;

Callconv didn't exist before, so extern was the only way to mark the calling convention. Now that we have callconv, the implicit calling convention isn't needed anymore.

[emekoi]

Communicate intent precisely.
Only one obvious way to do things.

[pixelherodev]

This would require a bit more work, but overall, I'm in favor of this.

Calling convention must then be defined. The default calling convention is "unspecified." For obvious reasons, this isn't usable for exported / extern functions (note: this proposal must also apply to export for the same reason). What should be needed instead is a valid, defined calling convention, which can be used both for exports and imports without issues.

[tadeokondrak]

I see the accepted label has been removed, and I don't support this change anymore.

Learning from the inline/callconv(.Inline) change and its reversal, I think that it sometimes makes sense for the syntax used the vast majority of the time to be a special case, and have a secondary syntax when it makes sense.

In the case of inline and extern, they're much more likely to be used than any other callconv expression, so it makes sense to use those, but keep the callconv syntax for other calling conventions that don't deserve their own keyword, and for selecting the callconv of a function based on a comptime variable.

I realized that this could apply to #1717 too, where typing the new syntax is significantly more inconvenient:

fn foo() i32 {}
const foo = fn() i32 {}

For all of these cases, there's a clear rule for when to use which: use the more verbose syntax when you need it, and the shorter syntax when you don't.

callconv inline/extern: use the keyword whenever it's constant in the code, and callconv otherwise.
fn: use the existing function syntax for almost everything, but use the expression syntax in an expression context (as a function argument, or a struct field).

[Whoops, accidentally posted the comment before I had a chance to finish/think about it. I guess it stays]

Another thought: the logic for fn could apply to struct, union, et cetera, but I don't think there's a reason to add alternative syntax at this point in the language's development and use.