#bind() macro

[brson]

We can probably take advantage of lambda-blocks' type inference (may need some tweaking still to make it work in more situations) to create a bind macro or extension that works for all function types, then get rid of bind.

[brson]

This would also be an easy way to pass functions with incompatible argument modes to higher-order functions.

[nikomatsakis]

I was thinking... I would perhaps like to go the opposite direction and make bind more special. The idea would be to omit the bind keyword, as in Scala. This would allow constructs like:

int::range(0, 10, _).filter(is_even, _).to_list();

In an ideal world, we could even support things like "_ + " (which work in Scala). When you go that far, though, the tricky part is to decide where the bind boundary is... for example, is ".foo(_)" equivalent to "bind .foo()" or "bind _.foo(bind _)"? Both make sense (Here, bind _ would effectively be the identity function).

Still, writing "my_vec.foldl(0, _ + _)" is pretty nice.

Anyway, the way I thought to implement this kind of thing (and to rewrite bind) is basically to have an AST node similar to the one which represents "{||...}" closures right now. So we'd get the inference of what kind of closure it is "for free".

[nikomatsakis]

#1649 discusses my proposal. It also discusses a change to the semantics of bind that occur as a result of my proposal and which would also (potentially) occur with this proposal.

[graydon]

Is this still relevant? I think it is not, given the discussion in #1649.