Expands help for error message E0161

[xfbs]

This error message gets triggered when someone wants to move a value in a trait object, for example:

pub trait Bar {
    fn finalize(self);
}

impl Bar for String {
    fn finalize(self) {}
}

fn main() {
    let boxed_trait: Box<dyn Bar> = Box::new(String::from("Hello"));
    // error!
    boxed_trait.finalize();
}

The existing message gives the advice of using a reference to self in the finalize() method. In general, this is sound advice for people who are new to Rust, where they may really intend to take a reference but are used to Python for example.

However, this does not address the situation where someone actually needs to move the value. One example is something where you have some kind of a builder pattern (or hash digester, or transaction reference) which have a finalize(self) method that you need to consume the boxed trait object as finalization can only be performed once.

In the case where:

• You know you will use your trait via boxed trait objects
• You need a method where self is consumed

You can achieve this in another way. This commit adds a suggestion for a possible workaround of using the Box<Self> pattern where one intends to move a self value in the case of using a boxed trait object.

pub trait Bar {
    fn finalize(self: Box<Self>);
}

impl Bar for String {
    fn finalize(self: Box<Self>) {}
}

fn main() {
    let boxed_trait: Box<dyn Bar> = Box::new(String::from("Hello"));
    // works!
    boxed_trait.finalize();
}

As this suggestion was very helpful to me, I would like to add it to the error code documentation for others to be able to find it easily as well. I do not replace the existing suggestion of using references, because in most cases that should be preferred. It is only when you know that your trait will always be used via boxed trait objects that this suggestion is the one you are looking for.

What do you think about this? I'm happy to hear some feedback if this is a good thing to add to the error message (or if there is an even better way that I had not thought about).

Cheers!

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[oli-obk]

r? compiler

[cjgillot]

Your PR does not pass CI because of too long lines.

[xfbs]

I have updated this PR:

• Fixed line length (using vim gq, so should wrap at 80 cols or so)
• Adjusted the code example to make it compile
• Expanded the text a little.

I'm not quite sure if the text phrasing is good, would be nice if someone looked it over :)

Cheers!

[xfbs]

@rustbot review

[cjgillot]

r? compiler

[davidtwco]

Apologies for the delay in getting to this, left a suggestion.

[davidtwco]

I think this is an improvement, but we should probably be a bit more general in our wording - as I expect there are more arbitrary self types that this is applicable to than just Box (using Box as an example is fine and good though).

[xfbs]

I will try to write it more generically!

I have not used arbitrary self types extensively before, usually only stuff like Box<Self> and Arc<Self>. So perhaps I was not quite sure on what is available and what makes sense, which is why I limited myself to only mention Box<Self>.

[Dylan-DPC]

@xfbs any updates on this? thanks