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
default.
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.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
