Ahh, I think I understand how things work much better now.
There are, as listed before, four function types now:
- fn: no closure
- sendfn: unique, immutable closure
- lambda: shared, immutable closure (a.k.a. fn@)
- block: mutable stack reference (a.k.a. fn&)
These types can be used in a hierarchy, where fn (having no closure)
is the most general, and block is the least general. That is, a fn
can be used as an argument where any of the other three are expected,
but a block can only be used where a block is expected. There's
currently a quirk to this: sendfn and lambda are not interchangeable
either way, so there are really two hierarchies:
- fn < lambda < block
- fn < sendfn < block
There are also currently three ways to define these functions, too,
they can't each be defined each way:
- fn xyz (arg) {...} - for fn only
- let xyz = fn (arg) {...} - for fn, sendfn, or lambda
- {|arg| ...} - for all (in progress)
So, if Rust did away with block, renaming block to fn, would the
behavior of fn definitions be preserved? Could the unified fn become
a type that could sometimes be used in places requiring a sendfn or a
lambda, but not always??
Earlier, I was imagining a hierarchy like fn < sendfn < lambda <
block, where it would seem logical to just knock it down to fn <
lambda < block. But there are things I have to learn about sendfn vs.
lambda...
Kevin
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
