Hacker News Reader

Comment by Animats | Hacker News Reader

I had this argument with the Rust folk. They use the term "closure" for things that don't reference any variables in the outer scope. Sometimes, all you need is a function pointer. For example:

  something.unwrap_or_else(|err| {
                     writeln!(io::stderr(), "{}", err);
                     process::exit(1);
                 }

This is really just a function call. There are no references to an outer scope. But Rust requires a closure there. You can't pass a pointer to a function.

You'd like for this to optimize down to a function call, without saving any state from the outer scope. Don't know if Rust does this yet.

View on HN

The term "closure" is used in Rust for that syntax, regardless of whether it actually closes over its environment. You need some term for the syntax, and closure is used even if it doesn't necessarily close over anything; because much of the time, you do use it because you want it to close over its environment.

And, you can pass a pointer to a function just fine:

  fn call_twice<F>(f: F) where F: Fn() {
      f();
      f();
  }

  fn hello() {
      println!("Hello");
  }

  fn main() {
      call_twice(|| println!("Hi!"));
      call_twice(hello);
      let x = 5;
      call_twice(|| println!("{}", x));
  }

And all of this optimizes down just fine; if the environment being closed over is empty, it will just be an anonymous function with no extra overhead. Heck, if you try it out yourself on the playpen in release mode, and take a look at the asm, all of these just get inlined right into main: http://is.gd/p9Kd9y

How about memory size? A pointer to a function is just a single pointer to the called code, while a pointer to a closure has at least 2 pieces of data (pointer to code + closed over data or reference) which seems incompatible.

Generics are monomorphized, so this isn't an issue.

Rust's lambdas are structs containing (references to) exactly the data from the parent scope that their bodies refer to, no more, no less. It's fine for that set to be empty, resulting in an empty, zero-sized value. As we discussed[1] recently, unique types + monomorphisation means that many/most calls of closures (i.e. even ones that capture variables) can compile down to an inlineable static function call. If there's no references to external data in the body, this function call is exactly what you want with a function pointer, except better, because it is not a virtual call. That is, the scheme that Rust and C++11 use for closures automatically gives a better result than passing pointers. (Passing a function value is the same, they have unique types just like closures, but with the ability to be coerced to C-style function pointers.)

By the way, function pointers have been able to be passed directly where closures, both the new and old forms, are expected since at least 0.13.

[1]: https://news.ycombinator.com/item?id=11054890

> But Rust requires a closure there. You can't pass a pointer to a function.

Actually, you can.

    fn perr(e: &str) {
        println!("There was an error :(, {}", e)
    }

    fn main() {
        Err("ERROR").unwrap_or_else(perr);
    }

The above code works, and can be run here: http://is.gd/2RCmG9

Ah. Thanks. I last tried this around Rust 1.0. Closures were still in flux back then.

Ah. Pre-1.0 we didn't have the Fn* traits. Closures were boxed (two closures with the same signature would have the same type due to this), and closures/functions were different types. You could declare an argument to be a closure or a function but not both.

Post "unboxed closures", closures are now stored on the stack (thus they usually optimize away; for example if you use an iterator with a bunch of adapters like filter/map it will optimize down to a for loop). Each closure has a unique anonymous type (you can box them if you want them to have the same type), and all closures implement one or more of the Fn* traits, as do function pointers. So arguments can be generic over all callables, and you can pass in a closure or a function or your own custom callable.

Only `proc` closures were boxed, `|...| -> ...` closures were pointers into the stack. However, it is true that all closures were type erased, and were hence equivalent to certain trait object types (`Box<FnOnce(...) -> ...>` for `proc`, and `&mut FnMut(...) -> ...` for the pipes).

Also, functions could coerce to either of the closure types, and hence be passed straight to functions expecting them.

> Also, functions could coerce to either of the closure types

Huh, I recall this not working. Perhaps I made a mistake then.

> closures were pointers into the stack

Ah, the type erasure was through &mut. TIL; I always thought it was Box only.

    fn main() {
        Err("ERROR").unwrap_or_else(perr);

}

gross.

> You'd like for this to optimize down to a function call, without saving any state from the outer scope. Don't know if Rust does this yet.

It does. Rust closures translate to a stack struct containing the capture and a method call on that struct. In this case, the struct is zero-sized, so it doesn't exist, so it's just a function call. Additionally, unwrap_or_else will probably be monomorphised and then inlined, so there will be no call at all.

"closure" is just the term for the syntax.

> You can't pass a pointer to a function.

Sure you can.

    fn main() {
        Ok(1).unwrap_or_else(inc);
    }
    
    fn inc(x: u8) -> u8 {
        x+1
    }

Both functions and closures implement the Fn* traits

> You'd like for this to optimize down to a function call, without saving any state from the outer scope. Don't know if Rust does this yet.

My (limited) understanding is that all bindings closed over by a closure are represented as anonymous struct passed to the function, if nothing is closed over that will be a unit struct which will of course be optimized to nothing.

Actually, even though in the language spec that usage is refered to as a "closure", when configured for a release build, that will compile to exactly the same code as if you had written a static funtion and passed a pointer to it.

Rust is very good at optimizing away closures to have as little overhead as is possible for the semantics they describe.

Reply on news.ycombinator.com