Per recent conversations, my current plan with regard to function types
is to pare us back to three:
- Unique closures (currently written "sendfn"), which can only close
over sendable state, which is either copied or moved into the closure;
- Shared closures (currently written "lambda" or "fn@"), which can copy
or move arbitrary state off the stack frame and access it;
- Blocks (currently written "block"), which access state from their
creator's stack frame by reference and therefore cannot be used once
their creator returns.
Native and bare functions can act as any sort of closure and will be
implicitly cast as needed. There will be some sort of library or perhaps
magic language feature to access get a native function as a pointer
(some sort of opaque pointer type) for interfacing with C libraries.
That part is hand wavy. Currently, the sugar syntax "{ |x, y| x+y }"
represents a block, but I have a patch that is *almost* ready where the
sugar syntax will represent any sort of closure. The correct kind will
be chosen using inference.
The question is: what should we call the various closure types? I think
we need both good prose names and good keywords, ideally those are the
same.
Some critiques of the current names:
- The original proposal was `fn~`, `fn@`, and `fn&`, which used to be
consistent with kinds; as the kinds have become words (`copy`, `send`),
these names are no longer consistent.
- Lambda is long and λ is unicode and not on my keyboard.
- Block is a homonym for plain old blocks like `{ foo(); bar(); }` which
is bad.
- I don't like the name "shared" in general, which we use for
task-local, boxed state, as it seems to imply sharing between threads.
Some suggestions for alternative names:
- Local or box closure for shared closure?
- Stack closure for block?
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
