Earlier, @Gankro wrote some tweets.
He linked to this blog post in particular, which describes the “autoclosure” attribute. This attribute causes a function to treat its arguments as if they were wrapped in a closure, delaying their evaluation until they are actually used in the function call.
I don’t know Swift super well, but I think the story on this is a bit more complicated in Rust. We care more about performance transparency than Swift does (in my impression), and ownership semantics definitely make wrapping arbitrary expressions in a closure a bit trickier.
I think this has some very valid use cases though (making assert a function isn’t one of them because it takes a fmt string). In particular, it seems like it could allow
Box::new to transparently use emplacement.
I’m concerned about the way placer syntax will impact people learning Rust. In particular, I’m concerned about a potention “to_string vs into” situation, in which people posting code for feedback will be told that they should be using
vec <- obj instead of
vec.push(obj), even when the performance implications are not significant. This throws a lot of complicated information at the user as they try to understand the concept of emplacement, the motivation for using it, the specifics of Rust’s placer syntax and semantics, and so on. It would be ideal if the method forms had the same internal semantics as placer syntax.
So this thread is just to raise these questions:
- What are some obvious use cases for autoclosure in Rust?
- What are the challenges to implementing this attribute i.r.t. Rust’s unique semantics and compilation model?
- Does the use case discussed above actually work? Can the closure passed to e.g.
vec::pushbe translated to the same semantics as