Clarify story on native functions

[nikomatsakis]

Right now, native functions have a distinct type from normal functions but there is no way to write it! The reason that the type is distinct used to be because the ABI for native functions was different. This caused a lot of bugs (#1059, #1058, #1174, #1179) so I implemented wrappers. I like the wrappers, it makes for very clean trans code. However, I also think it would be great to be able to pass around native C function pointers.

Basically I think we ought to decide between one of two options:

• keep the wrappers, merge native function types with normal functions
• ditch the wrappers, make it so that native functions are limited, and create a syntax for native fn types

If we do the latter, we'd have to fix the problems listed in the prior bugs. In some cases, like bind, we can just make it illegal. Cross-crate calls though probably ought to work (or maybe not?).

[nikomatsakis]

One use case for callable native function types that just occurred to me is that one might have C functions that return function pointers. Also, of course, that expect function pointers as arguments, but that case might be addressable just by having a way to get a void* that points to a C function.

[nikomatsakis]

I think that the consensus was that

• bare functions are now written native fn;
• native functions, for now, will also be typed as native fn, but eventually they will be native "abi" fn;
• the native * fn types will be a single function pointer.

The wrapper functions we generate today will be removed but I expect the shim functions will stay, as they are still needed to handle the various backends in a relatively simple way. For invoking native "abi" fn(T) -> U types where the link name is not known (i.e., by ptr), we'll need a "by ptr" shim (there would be one "by ptr" shim for every unique native type that is invoked in the crate). We could only have a "by ptr" shim and use it for all native function invocations with that type at the cost of an extra call by ptr (but it would reduce generated code size). Maybe we should start that way until the performance costs of native calls make us switch.

And of course there is always #1402 to contend with. But that's an internal change to the shim functions, basically.

[brson]

What does fn become when it's no longer a bare fn?

[nikomatsakis]

fn() is (already) "any closure"

[catamorphism]

@nikomatsakis Is this done?

[nikomatsakis]

Not to my knowledge.

[graydon]

I believe as of the meeting this week ( https://github.com/mozilla/rust/wiki/Meeting-weekly-2012-08-28 ) as well as the general direction outlined in #2082 (comment) we should have the story ... clarified, at least in principle. Not actually implemented yet. I'll leave this bug open to track progress on implementing the plan in the meeting.

(Also note: #3239 should be turned into a testcase for whatever's done here)

[pcwalton]

This is very old at this point.