-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support unboxed, uniquely typed closures #8622
Comments
This is not necessarily related to #6308 -- closure types are not considered dynamically sized in the latest plans. It is certainly related to the idea of replacing closures with traits. Basically goes all the way, removing also |
Not until Rust 2.0 |
The ability to modify the environment with The distinction would be marginally useful in the current system because |
I think this would remove the need for function bounds, since you would just take |
I really, really like this idea. (But I'm not a dev or anything.) But a problem is that if
(Again these are the same rules as if you were to substitute Unfortunately this means that if you want a reference to a mutating closure that you can actually call, you have to write |
A You wouldn't be able to mutate through an |
If you're referring to the "[if ...] and
But if you have |
You wouldn't be able to mutate the environment of |
I think that @glehel's point is the current rules allow |
When I say:
I mean the current definition of You couldn't convert an |
(Re: your previous comment) I understand that (and like it). I'm assuming here that the DST proposal is also in effect. Are you?
Right, and there would be a "new" To follow the trait analogy, restricting ourselves to single argument functions, consider the possible desugarings of
Which one would |
The ability to call an object would require compiler support, and wouldn't de-sugar to a method call. The closure trait bound would be special-cased to support the call syntax, and only give you a mutable environment when the object is mutable. I haven't really considered the ability to implement arbitrary callable objects as part of this - it's a magical capability like indexing on vectors or |
Right the trait desugaring was only intended as an analogy (and why I restricted it to single-argument). Possibly I'm being dense. Which part of the following would be illegal?
|
@glehel: ah, nevermind, I see what you've been saying now |
Another way to do this would be representing a stack closure as |
cc me |
I'm going to close this as obsoleted by the rust-lang/rfcs#77 proposal. If this or something along these lines is accepted, a new bug can be opened for implementing it without the now irrelevant discussion based on the Rust of nearly a year ago. |
It would need to be made obvious that these are generic functions/structs, because they won't be interchangeable.
Every closure would have either a unique type (like C++ closures) or at least a type based on the environment. A stack closure would start off as a bare moveable
fn(...)
implementation able to be converted to boxed&fn(...)
,~fn(...)
orRc<fn(...)>
objects.An unboxed closure would just be static dispatch without a function pointer. As with traits, you would choose between static/dynamic dispatch.
The text was updated successfully, but these errors were encountered: