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.

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

Revert "RFC to require impl MyStruct to be nearby the definition of MyStruct" #735

Merged
merged 1 commit into from
Feb 20, 2015

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Jan 26, 2015

The "Revised UFCS proposal", PR #132, makes the restriction imposed by PR #155 unnecessary:

Whenever a path like ...::a::... resolves to a type (but not a trait), it is rewritten (internally) to <...::a>::....

This applies to all non-trait impls, and because <T>::item has to be handled during type-checking, that removes any need to handle impls (or treat them as modules, for that matter) in resolution, eliminating
all the issues #155 was trying to solve by being overly conservative.

@eddyb
Copy link
Member Author

eddyb commented Jan 26, 2015

See also this comment about some of the consequences of UFCS.

@Kimundi
Copy link
Member

Kimundi commented Jan 26, 2015

Sounds good!

@nikomatsakis
Copy link
Contributor

I agree with the sentiment, however there remains some amount of impl work to be done before the arguments in the original RFC no longer apply, no?

@eddyb
Copy link
Member Author

eddyb commented Jan 27, 2015

Yes, hopefully I'll get to it in the next couple of weeks (I already figured out the details).

@netvl
Copy link

netvl commented Jan 27, 2015

Does this mean that it will be possible to write something like

pub struct SomeType { ... }

mod some_functionality {
    use super::SomeType;

    impl SomeType {
        fn do_something(&self) { ... }
    }

    fn free_func() {
        let s: SomeType = ...;
        s.do_something();
    }
}

or maybe even

pub struct SomeType { ... }

mod some_functionality {
    use super::SomeType;

    impl SomeType {
        fn do_something(&self) { ... }
    }
}

fn free_func() {
    let s: SomeType = ...;
    s.do_something();
}

? If so, it is great! It will help structuring programs immensely.

@eddyb
Copy link
Member Author

eddyb commented Jan 27, 2015

@netvl Both work before UFCS if you remove the restriction. I had a PR doing this a while back, it required amending the RFC and I never got back to it.
The difference between those and an impl in the same module is that SomeType::do_something wouldn't work right now (so you only got "extension methods" with that modification of mine).
With UFCS, SomeType::do_something would desugar to <SomeType>::do_something so you couldn't tell them apart.

@brson
Copy link
Contributor

brson commented Jan 29, 2015

👍 but instead of deleting the original RFC, @eddyb can we have a new RFC that reverses the design? It can be pretty short. I'd prefer to leave the RFC for historical purposes.

@eddyb
Copy link
Member Author

eddyb commented Jan 29, 2015

@brson I guess it could be something small explaining how UFCS allows resolution to ignore impls altogether. Will post that once I have an actual implementation.

@brson
Copy link
Contributor

brson commented Feb 20, 2015

Merged.

@eddyb eddyb deleted the revert-155 branch February 20, 2015 06:02
@Centril Centril added the A-typesystem Type system related proposals & ideas label Nov 23, 2018
@Centril Centril added A-impls Implementations related proposals & ideas A-inherent-impl Proposals related to inherent implementations labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-impls Implementations related proposals & ideas A-inherent-impl Proposals related to inherent implementations A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants