Skip to content

bare impls on same-crate different-mod imported types were useful and there is no alternative #18016

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
o11c opened this issue Oct 13, 2014 · 2 comments
Labels
A-type-system Area: Type system

Comments

@o11c
Copy link

o11c commented Oct 13, 2014

The following code used to work, but there is no longer any way to do this sort of thing.

Moving the impl into the mod can't be done because low-level modules need to remain similar to the C API they are wrapping, for example if they are generated; and unlike C it is not possible to reopen a module after it is closed.

Adding a meaningless trait does not work because trait methods cannot be called unless you import the trait.

Please bring back some way to do this (whispers of every crate being able to silently inject a prelude does not sound like a good idea at all).

pub mod really_a_crate
{
    pub use self::c::Foo;

    pub mod c
    {
        #[allow(non_camel_case_types)]
        #[repr(C)]
        pub enum Foo
        {
            FOO_A,
            FOO_B,
            FOO_C,
        }
    }

    impl c::Foo
    {
        pub fn frob(self)
        {
            println!("Hello, World!");
        }
    }
}

fn main()
{
    let foo: really_a_crate::Foo = really_a_crate::c::FOO_A;
    foo.frob();
}
@o11c
Copy link
Author

o11c commented Oct 14, 2014

related: #17376

@steveklabnik steveklabnik added the A-type-system Area: Type system label Jan 27, 2015
@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#749

lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…-result, r=Veykril

fix: use Result type aliases in "Wrap return type in Result" assist

This commit makes the "Wrap return type in Result" assist prefer type aliases of standard library type when the are in scope, use at least one generic parameter, and have the name `Result`.

The last restriction was made in an attempt to avoid false assumptions about which type the user is referring to, but that might be overly strict. We could also do something like this, in order of priority:
* Use the alias named "Result".
* Use any alias if only a single one is in scope, otherwise:
* Use the standard library type.

This is easy to add if others feel differently that is appropriate, just let me know.

Fixes rust-lang#17796
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

2 participants