-
Notifications
You must be signed in to change notification settings - Fork 13.4k
iteration library and lightweight bind syntax #1649
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
Comments
Hm. Might make parsing a bit sneaky, but if you can make it work I'm not opposed. |
One issue occurred to me. This is not so much related to the parsing as it is related to my efforts to make bind() and closures follow the same path through the code (right now, bind is different, and hence many things that should work actually don't, e.g., The change is that if I write It's not clear to me that it's a problem, but it's a change. It has some advantages. It allows the syntax to work with movable values, for example, in particular stack closures. That means something like:
works just fine even if The disadvantage of course is that complex expressions get re-evaluated each time the closure is invoked. |
This is a great idea. I've been talking about getting rid of the bind keyword in favour of such syntax for ages, but never actually did it. |
As a side effect, this fixes an existing bug in bind, which is that it ignored typestate predicates that were attached to the bound function. |
I'm ok with such changes. You've done some of this already though, yes? |
Further work on this is blocked on traits and regions, so bumping to 0.3. |
iter trait approach is basically there, though traits are needed to make it nice. |
* No longer use variables for locating the action. * Modified path. * Turned off action check until image is released to public. This will fail with permissions issue until then.
I am working on a nicer iteration library. This requires a lightweight bind syntax. I am working on that too. You can see current status and get a flavor from the cargo package "iter", though the eventual plan is to move that into libcore (or libstd?)
The bind extension is that the
bind
keyword will no longer be required. So one can writefoo(a, b, _)
which means precisely the same thing asbind foo(a, b, _)
used to, except that I plan to infer whether to use a boxed closure, stack closure, etc. It will also work for receivers, like_.foo(_)
. The plan is to have the code path in the compiler be very similar to the one used for closures (trans_bind
, for example, should go away completely).The text was updated successfully, but these errors were encountered: