Add alternative to Conservative Impl Trait (1522)

[earthengine]

A new approach to return unboxed closures is proposed.

Rendered

[Ixrec]

This RFC confuses me greatly. It appears to be unaware of #1951 which is now in FCP, and I can't figure out what this RFC is actually proposing as most of it sounds like a description of what's already been on nightly for a while.

What's the actual change being proposed here?

[TimNN]

Note that this is an amendment to the existing conservative impl trait RFC (diff) adding a section to the alternatives section.

[Ixrec]

@TimNN Ah, thanks, now it makes perfect sense.

[nixpulvis]

Turns out GitHub isn't a very good forum for RFCs 😢

[cramertj]

These aren't equivalent. In the first function, you're returning a closure which can be evaluated with another argument at a later time. In the second, you're delaying running the function at all until it has been called with the last argument.

Consider, for example, the case where you add a println!("Hello!"); to the beginning of each fix function:

let func = |_| {};

// With `fix` version 1:
let closure = fix(func); // prints "Hello!"
closure(1); // Runs the closure, prints nothing
closure(1); // Runs the closure again, prints nothing

// With `fix` version 2:
let closure = |t| fix(func, t); // prints nothing
closure(1); // prints "Hello!"
closure(1); // prints "Hello!"

[ahicks92]

I don't fully follow the alternative being proposed here, but nonetheless the point of impl trait is much wider than just closures, and the implementation needed to take it the last inch after we have it should be basically trivial given that closures are already standard types implementing a trait.

Why is this better, unless we're going to throw out the rest of the RFC or something?

[earthengine]

Let me clarify of this issue. This is not intended to imply any work to be done on the current impl Trait implementation. Instead, the section is added to show a potential workaround, which can be used to simulate the the lacking feature. This is mean to be a historical record, for some research interest.

Some of the comments above is correct, this approach is good for return-by-name, not so good for return-by-value. But in my opinion in many cases this difference is no very important.

[eddyb]

@earthengine Try using your technique to return an iterator containing a closure (e.g. .map).

[aturon]

Thanks much for writing this up, but the lang team is swamped enough with new RFCs that we don't want to spend time hashing out additions to the amendment sections of existing ones. Feel free to open a thread on internals if you think this could lead to a new RFC, though!