[rust-dev] names needed for function types

Graydon Hoare graydon at mozilla.com
Tue Jan 3 13:30:05 PST 2012


On 11-12-30 10:00 AM, Niko Matsakis wrote:

> I like the idea that "fn" is just the type of a general closure (i.e.,
> "block"). I agree it's what you want most of the time. I think that
> there are then three logical choices for boxed/unique closures:
>
> 1. `fn@` and `fn~`: this is intended to emphasize the fact that the
> environment is referenced by a boxed/unique pointer. I don't know how
> intuitive it is and it makes heavy use of sigils.

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 the symmetry between fn@ and @ intuitive here, as with fn~ and ~. 
The sigil *does* describe the uniqueness / sharedness of the closure 
here, exactly. Especially since, inside a fn~, you can only capture ~ 
boxes. If you want to capture @ boxes you have to use a fn at .

I agree that the previous issue we had with kinds overloading the @ and 
~ sigils turned out to be much more counter-intuitive. Here the 
intuition you get from the sigil is the correct one. I think. I'd at 
least like to try it, unless there's a real chorus of dissent. I think 
it'll work ok.

(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.)

> 2. `copyfn` or `sendfn`: this emphasizes the kind restrictions. This is
> also nice because a `copyfn` is copyable and a `sendfn` is sendable,
> whereas a plain `fn` is neither.

Don't like #2 here, no.

> 3. `fn[copy]` and `fn[send]`: an alternate version of #2 that I find
> more visually appealing.

Second choice here. They're ... ok, but the collision with capture 
clauses seems pretty unfortunate.

-Graydon


More information about the Rust-dev mailing list