[rust-dev] names needed for function types

Niko Matsakis niko at alum.mit.edu
Wed Jan 4 15:49:35 PST 2012

On 1/3/12 1:30 PM, Graydon Hoare wrote:

> [Regarding fn@ and fn~]:
> Personally this is still my preference by a wide margin. fn is what 
> you'll write almost-all-the-time anyways, so it's not like your 
> program will be overwhelmed with sigils. 

I find this fairly persuasive.  The fact that `@` and `~` also 
correspond to the kinds of heap pointers that can be captured---as well 
as the way that the environment is referenced---is a very good point.
> (I notice you don't mention "raw" or "native" functions in this 
> discussion. Any thoughts on them? They're what we reserved 'fn' for 
> last time through this mess.) 

Yeah, I've been thinking about it.  The original proposal where "fn" was 
just a function pointer and "fn sigil" indicated a closure has a 
definite elegance to it, though it seems that in practice it's the wrong 

I guess the main question is when we would need to have raw/native 
function pointers and what we expect to do with them.  At some point 
Marijn proposed that we just have some way to get a raw function pointer 
basically as an opaque value (`*void`, essentially).  This would be ok 
for passing to C code but not useful within Rust itself.

If we think we'll want to be calling native functions by pointer from 
within Rust, we could support a type like `native "abi" fn(T) -> U`.  
It's a bit of mouthful but you do need to know the ABI to call the 
function.  This could also be used for a plain Rust function pointer 
(`native "rust" fn`).  I had also thought something like `fnptr(T)->U` 
but I'm not sure where to squeeze in the ABI.


More information about the Rust-dev mailing list