Skip to content

RFC: goto-definition between From::from and Into::into #18316

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.

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

Closed
ShoyuVanilla opened this issue Oct 17, 2024 · 4 comments · Fixed by #18934
Closed

RFC: goto-definition between From::from and Into::into #18316

ShoyuVanilla opened this issue Oct 17, 2024 · 4 comments · Fixed by #18934
Assignees
Labels
A-ide general IDE features C-feature Category: feature request

Comments

@ShoyuVanilla
Copy link
Member

Currently if we trigger goto defintion here;

struct Foo;

fn foo() -> Foo {
    struct Bar;
    impl From<Bar> for Foo {
        fn from(_: Bar) -> Self {
            Foo
        }
    }
    Bar.into$0()
}

it just takes us to std::convert::Into<T>::into, because we do not have manual implementation of impl Into<Foo> for Bar here.

I think that it would be reasonable to provide two definition sources, std::convert::Into<T>::into(..) with the above fn from(..) inside the impl From<Bar> for Foo { .. } block as well, and implement similar thing to the opposite direction from(..) -> into(..).

@ShoyuVanilla ShoyuVanilla added A-ide general IDE features C-feature Category: feature request labels Oct 17, 2024
@Veykril
Copy link
Member

Veykril commented Oct 17, 2024

Sounds reasonable to me

@flodiebold
Copy link
Member

CC #15315, #8373

@Veykril
Copy link
Member

Veykril commented Oct 17, 2024

Those would be the ideal solution, but assuming this special case isn't much work to implement I think it would be fine for us to special case From/Into here? For the time being at least, as those issues seem a fair bit more complicated to pull off to me

@ShoyuVanilla
Copy link
Member Author

I'm asking this just out of curiosity 😅
I think that solving monomorphization in #15315 is preferable but could "skipping generic intermediates" in general without hard-coding for each well known traits be possible?
I think that the relationship between such "dual" traits are not so much clear in code.
Though Into's blanket implementation calls from(..) inside into(..) method but concluding such "dual" relationship from such calls inside blanket implementation's method body seems quite arbitrary, without our common sense that they are "dual".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ide general IDE features C-feature Category: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants