Book: ch20-05: expand on why closure takes ownership of self when called

[dlukes]

The error resulting from calling the closure sent through the channel is indeed very cryptic, kudos for explaining it so well! The one part that baffled me for a while was "when we call the closure, it takes ownership of self" -- was this just something one has to know?

Then I saw the definition of the FnOnce trait, specifically the signature of call_once(), and everything clicked into place:

pub trait FnOnce<Args> {
    type Output;
    extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
}

If calling a closure basically desugars to calling its call_once() method, which takes ownership of self, then it makes perfect sense that self needs to be sized (otherwise it couldn't be used as function argument).

I think it might be a good idea to extend the discussion just a little and include the FnOnce trait definition. Personally, it helped me achieve a much clearer grasp of what's happening (unless what I've written above is a load of nonsense :sweat_smile:), maybe it'll help other people too.

[carols10cents]

If calling a closure basically desugars to calling its call_once() method, which takes ownership of self, then it makes perfect sense that self needs to be sized (otherwise it couldn't be used as function argument).

It's not every closure -- it depends on what the closure is doing :) We discuss the closure traits FnOnce, Fn, and FnMut in Chapter 13, would a reference back to that section be sufficient, do you think?

[dlukes]

It's not every closure -- it depends on what the closure is doing :)

Sorry, I meant "calling a FnOnce closure", of course :) That always desugars to call_once(), doesn't it?

would a reference back to that section be sufficient, do you think?

Well Chapter 13 doesn't really cover how the closure traits are implemented, does it? As far as I can Ctrl-F, there's no mention of the call_once() method. Seeing the signature of call_once() is what made me understad why the closure takes ownership of self when it's called, or indeed what that might even mean. So it's more about adding one further bit of new material that expands on ground previously covered in Chapter 13, rather than just referencing the chapter (which in itself is unnecessary, imho, I think it's pretty clear to the reader that that's the place to go to brush up on a comprehensive discussion of closures).

On the other hand, I understand the reticence to get too sidetracked explaining a quirk instead of focusing on the topic of the chapter.

On the third hand, some readers (like myself) won't be able to carry on with the topic of the chapter anyway, until they feel they have at least a roughly satisfactory idea of what the quirk's about, and this might help :)

[carols10cents]

On the other hand, I understand the reticence to get too sidetracked explaining a quirk instead of focusing on the topic of the chapter.

I think this is the choice we're going to make for this chapter. There are already a lot of asides about various details in chapter 20, some of which we're trying to strip away to streamline this chapter a bit, and I think people interested in the implementation details of FnOnce closures can seek out help online :)

Thank you for the feedback though!