[rust-dev] names needed for function types
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.
More information about the Rust-dev