I'm ok with this, but I agree with Graydon re. the second issue, and
regarding nesting I think the rules should be as simple as possible. The
danger of eliminating the keyword "bind" is that now the lambda is
implicit and it needs to be very clear what's going on -- the eye needs
to be able to infer where the lambda is. I'm a little worried about how
mind-twisting the scoping examples you gave were.
I think solution #2 -- that we need to accept _.b(_) but only if b()
turns out to be a method, as you said -- is the right one. (Also, I hate
to bring it up again, but '->' for methods solves this...)
Supporting bind on operators is a bit more perilous from a readability
standpoint, I'd tend to think, because now it's not just
PrimaryExpressions (in the Java sense) that a reader has to worry about
to find where the lambdas are but many grammar productions. To make this
concrete, the grammar for PrimaryExpression could be something like
(simplified):
PrimaryExpression ::== MethodCall | FunctionCall | '(' Expression ')' |
Identifier | Literal
MethodCall ::== PrimaryOrUnderscore '.' Identifier '('
ExpressionOrUnderscore (',' ExpressionOrUnderscore)* ')'
FunctionCall ::== PrimaryOrUnderscore '(' ExpressionOrUnderscore (','
ExpressionOrUnderscore)* ')'
PrimaryOrUnderscore ::== '_' | PrimaryExpression
ExpressionOrUnderscore ::== '_' | Expression
Here, assuming I understand your proposal correctly, the rule is
relatively simple: where there's an underscore, the lambda is always
positioned before the nearest parent PrimaryExpression. But with
operators, the rules become more complex. I don't know if most
programmers would have an intuition about what "_ + _ * _" means, for
example.
But generally I like the proposal as a whole -- it's a nice bit of
syntactic sugar.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
