Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rule around non-dispatchable functions doesn't match the compiler behavior #1247

Open
upsuper opened this issue Aug 12, 2022 · 5 comments · May be fixed by #1248 or #1455
Open

Rule around non-dispatchable functions doesn't match the compiler behavior #1247

upsuper opened this issue Aug 12, 2022 · 5 comments · May be fixed by #1248 or #1455
Labels
A-types Area: Types Language Cleanup Improvements to existing language which is correct but not clear, or missing examples, or the like.

Comments

@upsuper
Copy link
Contributor

upsuper commented Aug 12, 2022

In the Object Safety section, it says:

  • Explicitly non-dispatchable functions require:
    • Have a where Self: Sized bound (receiver type of Self (i.e. self) implies this).

This implies that if you have any associated function with receiver of self should be counted as non-dispatchable function. However, it is not the case. See the following code:

trait Foo {
    fn a(self);
    // fn b(self, x: &Self);
    // fn c(self) -> Self;
}

fn test() -> Box<dyn Foo> { todo!() }

Uncommenting b or c would make the code fail to compile, unless explicit where Self: Sized is added, but the rule in the reference indicates that having a receiver self already implies that bound exists.

Not sure whether it's something that should be fixed in the reference or the compiler.
@bjorn3
Copy link
Member

bjorn3 commented Aug 12, 2022

a is actually dispatchable when the unstable #![feature(unsized_fn_params)] is enabled.

@upsuper
Copy link
Contributor Author

upsuper commented Aug 12, 2022

Sounds like the reference should remove "receiver type of Self (i.e. self) implies this", and possibly mention that while self in receiver doesn't violate object safety, unsized_fn_params is required to actually use it as dispatchable.

@ehuss ehuss added the A-types Area: Types label Aug 12, 2022
@upsuper upsuper linked a pull request Aug 13, 2022 that will close this issue
Open
@Havvy
Copy link
Contributor

Havvy commented Aug 14, 2022

Okay, looking into this way too long, I think I understand what the original author meant by the parenthetical. Specifically, having a bound of Self: Sized is implied by having the receiver be self because it is a requirement that the programmer specify that Self: Sized on the method or it won't compile.

I don't like parentheticals at all and would rather it be a note using the note notation explaining it similarly to how I just wrote it. Though not exactly; the word "implied" should not be used at all since it is confusing as evidence by this issue.

We also have a policy of discussing Rust as it currently exists. We don't talk about unstable features. So any fix for this issue should not mention them.

@Havvy Havvy added the Language Cleanup Improvements to existing language which is correct but not clear, or missing examples, or the like. label Aug 14, 2022
@upsuper
Copy link
Contributor Author

upsuper commented Aug 14, 2022

Specifically, having a bound of Self: Sized is implied by having the receiver be self because it is a requirement that the programmer specify that Self: Sized on the method or it won't compile.

However, this is not true. As the example shows, fn a(self); compiles totally fine in stable Rust, so the logic is more consistent if we understand it as a dispatchable rather than a (implied or not) non-dispatchable.

@Havvy
Copy link
Contributor

Havvy commented Aug 14, 2022

Oh, yeah. I tried fn a(self) {} and that failed asking to add the Sized bound. And I can even create a value of Box<dyn Foo> but I get errors if I try to call a on it. So yeah, the entire parenthetical can just be removed then.

@ehuss ehuss mentioned this issue Jan 1, 2024
Closed
@steffahn steffahn linked a pull request Jan 26, 2024 that will close this issue
Open
@traviscross traviscross mentioned this issue Jul 2, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-types Area: Types Language Cleanup Improvements to existing language which is correct but not clear, or missing examples, or the like.
Projects
None yet
Milestone
No milestone
4 participants
@ehuss @upsuper @Havvy @bjorn3