Simple partial application

[drXor]

I don’t think there’s such a promise about explicitness.

Sure, I think my wording was poor here. The point I meant to make was that, AFAIK, there is no place where it is possible to create a closure without a double bar, and I think that sort of visual signaling is useful. I spend a lot more time reading others’ code than writing my own, and being able to see at the call site that a closure, and not a value, is being passed is valuable for readability. For comparison, Scala’s def foo(f: => A) (by-name parameters) creates lambdas out of bare expressions, which are convenient when writing code but make it frustrating to determine if a function call is secretly constructing a lambda, since I might need to jump to a different file.

I think one can argue that this sort of sugar is comparatively harmless, like auto-deref, but for now I remain skeptical.

Note that the type of foo is not turned into:

fn(i32) -> (impl FnOnce(i32) -> (impl FnOnce(i32) -> i32))

Any implicit currying in my idea is sugar.

I don’t know that I suggested otherwise? I assumed your proposal was like Scala’s foo(1) _ syntax, rather than Haskell’s bona-fide curried functions.

But Rust is not a language with function overloading.

No, but function overloading is a feature present in many popular languages (e.g. Java, C++) that is orthogonal to currying. This syntax would probably leave a lot of new Rust users scratching their heads. I don’t think an argument can be made for this like was made for using try blocks; at least try blocks involve code that needs error-handling.

Haskell does group function parameters in parenthesis if you pass them as a tuple. […] In Rust, what you’re really doing is passing a tuple:

I think comparing Haskell and and Rust syntax is just going to lead us astray. For example, in Haskell, I can write the following, since every function in Haskell takes exactly one parameter (modulo sugar to make it look like functions can take multiple parameters).

foo :: (t, t) -> t
foo (a, _) = a

t12 = (1, 2)
f12 = foo t12
-- alternatively,
f12 = foo (1, 2)

This does not work in Rust, since functions can take more than one parameter:

fn foo<T>(a: T, _: T) -> T { a }

let t12 = (1, 2);
let f12 = foo(t12); // error[E0061]: this function takes 2 parameters but 1 parameter was supplied
// this is the only correct alternative
let f12 = foo(1, 2);

[Centril]

call site that a closure, and not a value, is being passed is valuable for readability

Not sure why that is valuable; after all, a closure is a value. If the function foo was explicitly written as:

fn foo(x: u8) -> impl Fn(u8) -> u8 {
    move |y| x + y
}

… you would not be able to tell from foo(x) whether or not a lambda or a non-lambda is returned… However, the language is currently making currying quite cumbersome even with -> impl Trait; If you write foo this way then you can’t write foo(1, 2) anymore.

I think one can argue that this sort of sugar is comparatively harmless, like auto-deref, but for now I remain skeptical.

Auto-deref is a great example of such implicitness working fine. I don’t think implicit currying is any more magical than that, or more problematic.

I don’t know that I suggested otherwise?

I was clarifying for the audience

I assumed your proposal was like Scala’s foo(1) _ syntax, rather than Haskell’s bona-fide curried functions.

I’m not particularly familiar with Scala; got a link to the documentation?

No, but function overloading is a feature present in many popular languages (e.g. Java, C++) that is orthogonal to currying. This syntax would probably leave a lot of new Rust users scratching their heads.

Fair enough; I think it is fairly easy to teach this tho and can be done early in the teaching material.

For example, in Haskell, I can write the following, since every function in Haskell takes exactly one parameter

This is true. But we could also do that;

fn foo (x: i32) -> (y: i32) -> (z: i32) -> i32 { x + y + z }

Here, foo is a proper curried function. It might not be particularly useful to do this distinction and instead just allow the implicit currying because it would work well with the current ecosystem and solves the problem equally well while at the same time being a much smaller change.

[drXor]

Not sure why that is valuable; after all, a closure is a value.

Closures are values, but that’s missing the forest for the trees. Suppose I’m reading another engineer’s code and I want figure out what their intent was:

// here, it's immediately clear that a closure is capturing 
// behavior to be executed elsewhere
foo.do_something(|x| bar(1, y, x));

// it's not immediately clear if the value being passed is
// a scalar (whatever `bar` returns) or a closure; 
// in fact, I'd assume that the return value of `bar` is 
// what's being passed
foo.do_something(bar(1, y));

Of course, this is a strawman, and it ultimately comes down to taste. (Warning, personal opinion incoming) Rust has just the right amount of local inference that I can look at a piece of code and guess what it’s doing without looking up every function declared in a different file.

Auto-deref is a great example of such implicitness working fine. I don’t think implicit currying is any more magical than that, or more problematic.

I think the jury’s out on that. Our opinions on the matter are clear, but let’s wait and see what other folks think.

I’m not particularly familiar with Scala; got a link to the documentation?

This SO answer gives a neat explanation of it. f(x) _ desugars to y => f(x)(y), as in your proposal. AFAIK the underscore is there to disambiguate type inference (since Scala has overloading), and not to make it clear that what comes out is an anonymous function. This is opposed to Haskell’s currying, where functions truly only take one parameter and always return functions, so that f x y z is really (((f x) y) z).

This is true. But we could also do that;

Too little too late, if you ask me. Haskell as designed with currying from the onset, so all of the standard library functions have parameters in “the most reasonable order” for currying purposes, e.g. map :: (a -> b) -> [a] -> [b]. Not so for Rust; for example, Iterator::map is fn (impl Iterator<Item = T>, impl FnOnce(T) -> U) -> impl Iterator<Item = U>, which limits potential usefulness of currying. Being able to write || _.map(f), with or without the bars, would achieve a closer purpose.

Again, I don’t think we’re going to convince each other; I’d like to see what other people think of our respective proposals.

[Centril]

Our opinions on the matter are clear, but let’s wait and see what other folks think.

Aight

Again, I don’t think we’re going to convince each other;

Don’t say never. I was somewhat neutral on adding (x: i32) -> (y: i32) -> ... You’ve at least convinced me that this is a bad idea. Your note about designing the standard library (and other notable packages/crates) with currying in mind is spot on and very true.

[madmalik]

Before further discussion if and how it would be useful… is it even possible?

Say, the proposal is desugaring f(_, y, _) to |x, z| f(x, y, z) and _.foo() to |x| x.foo(). Would that even work, given that one has to sprinkle a fair amount of *s and &s into closures?

[scottmcm]

Some of these partial application syntax proposals are approaching https://www.boost.org/libs/lambda, which added lambdas to C++ as a library. For example, one could do _1 * 2 for what rust calls |x| x * 2. I suspect nightly Rust could do something similar today. (Nightly to be able to implement the Fn* traits.)

The biggest problem that has is figuring out the extent of the lambda:

• How does one decide if foo().bar(_) is |x| foo().bar(x) or match foo() { t => |x| t.bar(x) }? (Not unlike the postfix macro discussions.)
• If one has foo(_, _), is that |x, y| foo(x, y) or |x| |y| foo(x, y), or something else? Can one do the other?

So I’m not sure how much value there is there over |x|, which just isn’t that long.

(That said, currying can certainly be useful, so part of me likes the idea of being able to declare things as fn foo(x: i32)(y: i32) -> i32 so that foo(2): Fn(i32)->i32. But then it’d always be foo(1)(2), never foo(1, 2).)

[MajorBreakfast]

And this “closure noise” is actually the reason for this idea using _ as a parameter standin. There’s no suprise-capable calling of a function with not enough arguments, as the positions are filled. And because they’re filled with a placeholder, it can be understood that it’s a delayed evaluation of the partially applied function.

It’s not as obvious as you suggest. We use “_” as placeholder in a plethora of places today already:

let x : &'_ _ = &foo(|_| 42);

match (1, 2) {
  (_, _) => { println!("Hello! x = {}", x); }
}

Playground Link

Spotting partial application reliably would be difficult: Each “_” could indicate partial application or it could be just some other placeholder. OTOH the closure syntax that we have today can be spotted easily because its notation makes it obvious. IMO it’s also short enough. I never felt that it was too verbose.

Edit: Another notable difference is that all uses of “_” today have something in common: The “_” serves as placeholder for something that is of no interest. Using it as placeholder in partial application would be something else entirely because it would represent a parameter.

[madmalik]

Another notable difference is that all uses of “” today have something in common: The “” serves as placeholder for something that is of no interest. Using it as placeholder in partial application would be something else entirely because it would represent a parameter.

I think _ is the wrong token for this too. I’d prefer something like $, as it stands out and there is prior art for using $ for unnamed parameters.

I didn’t want to mention it until there is some consensus if something like that is even desirable.

[madmalik]

A social solution to this problem would be to standardize junk names for usage in closures. If everyone uses the same one character names it becomes easier to ignore them. Looking at code in the wild, we’re already halfway there with x, y and z.

[troiganto]

One particularly annoying pattern I’ve come across is wanting to turn an impl Iterator<&T> into an impl Iterator<T> where T: Copy . This can be accomplished with a very simple closure: iter.map(|x| *x) , but I can’t help but want to reach for iter.map(*_) , as I might have written in Scala

Slightly off-topic, but are you, per-chance, thinking of Iterator::cloned()?

[Centril]

So I’m not sure how much value there is there over |x| , which just isn’t that long.

IMO it’s also short enough. I never felt that it was too verbose.

It’s not about length; it is about forcing me to come up with descriptive identifiers for the lambda binders just for the parameter passing, which is irrelevant to the algorithm described in the code. I could just use one letter identifiers for the binders, – and I will eventually do that if I have to write a lot of lambdas… – but one letter identifiers makes me feel rather bad, since it adds no useful information for the reader.

PS: my reddit nick is etareduce so that should tell you how I feel about these type of lambdas…

[Ixrec]

Some not-technically-prior art: Javascript is thinking of using ? for this. Personally, that’s a syntax I would not mind at all in JS or Rust. Though I don’t know Rust’s grammar well enough to tell if it’d be unambiguous. And Rust’s ? is way more popular than JS’s ?: ternary operator.

[drXor]

The biggest problem that has is figuring out the extent of the lambda:

• How does one decide if foo().bar(_) is |x| foo().bar(x) or match foo() { t => |x| t.bar(x) } ? (Not unlike the postfix macro discussions.)
• If one has foo(_, _) , is that |x, y| foo(x, y) or |x| |y| foo(x, y) , or something else? Can one do the other?

These problems are partially sidestepped by my proposal to require || before a partial application: in this syntax, it is clear that || foo().bar(_) becomes |x| foo().bar(x). However, it’s not clear what || || foo(_, _) should do; if I had to guess, I’d say || |x, y| foo(x, y).

Edit: Another notable difference is that all uses of “_” today have something in common: The “ _ ” serves as placeholder for something that is of no interest. Using it as placeholder in partial application would be something else entirely because it would represent a parameter.

Looking at prior art, Scala jumped this ship a while ago, since it uses the “wunderbar” for both purposes:

// define mutable foo to have the default value for `Int`
var foo: Int = _ 

// don't bind parts of a match
(foo, bar) match {
    case (0, _) => println("zero!")
    case _ => println("something else")
}

// erased type parameter, equivalent to Java's Foo<?>
// (NOT please-infer-the-paramter-for-me, unlike Rust)
def foo: Foo[_] = .. 

// equivalent to xs.map { x, y => x + y }, the syntax we're 
// discussing today
xs.map(_ + _) 

I tend to read _ as “I want a variable here but I don’t want to give it a name so I’ll let the compiler make one for me”. This is a valid interpretation of things like let _ = ..;, only that you can’t pronounce that “variable”, so it can be elided.

I think _ is the wrong token for this too. I’d prefer something like $ , as it stands out and there is prior art for using $ for unnamed parameters.

This is just my personal taste, but the $ is kind of ugly.

Some not-technically-prior art: Javascript is thinking of using ? for this . Personally, that’s a syntax I would not mind at all in JS or Rust. Though I don’t know Rust’s grammar well enough to tell if it’d be unambiguous. And Rust’s ? is way more popular than JS’s ?: ternary operator.

I feel like ? is just asking for readability trouble: imagine something like iter.map(?.foo()?.bar()), or worse still, iter.map(-?)! I think a lot of us are trained to think Result-propagation when we see ? and it’d be pretty jarring!

Swatches for the above syntaces (though I think we’re just arguing about paint colors at this point).

iter.map(foo(1, $, $));
iter.map(-$);
iter.map($ + $);
iter.map($.foo($));

iter.map(foo(1, ?, ?));
iter.map(-?);
iter.map(? + ?);
iter.map(?.foo(?));

// for comparison, my proposal:
iter.map(|| foo(1, _, _));
iter.map(|| -_);
iter.map(|| _ + _);
iter.map(|| _.foo(_));

[Centril]

I want to retain the ability to use _ for inference; right now it is only used in type context for that, but foo(_, 3) could be value inference in a dependently typed setting.

[CAD97]

This is just my personal taste, but the $ is kind of ugly.

Get a better font then! https://fonts.google.com/?category=Monospace

But honestly, I use Fira Mono (or rather, Fira Code), and I like the glyph in that font. Source Code Pro also has a good . I’ve got a user stylesheet in Firefox such that I haven’t seen Consolas code for over a year until taking the below screenshot, and I agree that the Consolas is bad looking.

Font Preview

• Fira Code
  
• Source Code Pro
  
• Consolas
  

[drXor]

I want to retain the ability to use _ for inference; right now it is only used in type context for that, but foo(_, 3) could be value inference in a dependently typed setting.

The only practical application I can imagine is things like foo([x; _]), which I don’t find terribly compelling. Can you elaborate on what you envision this being useful for? I’m not saying this is a bad idea, but I don’t think it’s worth applying stop energy over a feature that I can’t imagine there being an RFC for any time soon (const generics are not dependent types iirc).

[Tom-Phinney]

$ is one of the few ASCII characters used in Rust that is absent from many non-US keyboards. Have pity on your colleagues outside the States and choose something other than the currency character of a limited set of countries.

To understand the problem, what if the chosen symbol were €, which is not on most US keyboards?

Here’s an appropriate listing of candidate currency symbols. A number of them seem attractive.

[gbutler]

$ is one of the few ASCII characters used in Rust that is absent from many non-US keyboards. Have pity on your colleagues outside the States and choose something other than the currency character of a limited set of countries.

You must go Lou Ferigno with Perl then?

[Tom-Phinney]

You must go Lou Ferigno with Perl then?

I don’t care about the long-term evolution and survival of Perl. I do care about Rust; it offers a way out of the cyber-security morass inherent in other current programming languages.

[iopq]

I kind of hate closure noise. Even very simple examples like .filter(|&x|second(x)(i))

I get a bit confused because I have to make sure the precedence is correct

I prefer .filter(apply(second, i)) which is point-free, even if I have to write my own apply function which only does move |a| f(a)(b)